[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
|