[myhdl-list] Re: Cosimulation with the simple FSM example.
Brought to you by:
jandecaluwe
From: Jan D. <ja...@ja...> - 2006-01-04 19:59:26
|
George Pantazopoulos wrote: >>====Begin==== >>from myhdl import * >> >>t_State = enum('SEARCH', 'CONFIRM', 'SYNC', encoding='one_hot') >>ACTIVE_LOW = 0 >>FRAME_SIZE = 8 >> > > > Jan, > > Ever since trying myHDL I've been using plain integers to define states > for all my code. Ok, let's insert a promotional break then :-) Despite the issues (when going to low-level Verilog), I believe enum is a very valuable high-level thing - it's in MyHDL because I liked it so much in VHDL. Moreover, the possibility to specify the encoding in MyHDL (basically giving you a trade-off between nr of flipflops and logic delay right from the high-level code) is a unique feature, that I always had wanted when still doing VHDL/Verilog/Synopsys. > In one of my modules where I tried using the enum, I > noticed that I got incorrect behavior (incorrect initial states, I > believe) if I didn't specify the encoding style. It worked correctly > when I specified 'encoding=one_cold'. I haven't tried other encoding > styles. > This was in the synthesized hardware (Xilinx ISE w/XST). I didn't > co-simulate this module. Is this dependence on encoding type something to > be expected when doing synthesis? Certainly not. It should always work. Out of the 3 possible encodings the default (binary) is the "least risky": as the initial state will be all zero's (often the default in fpga's), things may still work when your reset sequence doesn't work as it should. Moreover, once in the Verilog domain, binary encoding is basically identical to the simplest use of plain integers. So the problems you report are the opposite of what I would expect, and I haven't a clue on what went wrong. Cosimulation may help to clarify things in the future :-) Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |