EDK : FSL macros defined by Xilinx are wrong

[Bob Perlman]

On Mon, 21 Nov 2005 04:44:45 -0800, "Georgios Sidiropoulos"
<me00569@cc.uoi.gr> wrote:

I would like to monitor the functionality of a state machine
I have designed using ISE 7.1. Is there a way to retain the state

names (i.e. reset_state,idle_state,run_state)in the modelsim post
place and route simulation? I find it more convienient to see the
state names than the values of the chosen fsm encoding type.

In each FSM I include a special section of code that assigns an ASCII
string with the name of the current state to a reg variable. I then
display the reg variable in the Modelsim waveform viewer in ASCII
format. This section of code is inside an 'ifdef statement that is
visible to the simulation tool but not the synthesizer. In Verilog
it'd look like this:

`ifdef synthesis
`else
//---- ASCII string code goes here
`endif

Bob Perlman
Cambrian Design Works

 

[Andy Peters]

Mike Treseler wrote:

Hal Murray wrote:
I thought that consensus here was to use the global
reset hardware to (asynchronously) force your state
machines into a known state and then use a local
FF that has been synchronized to get out of that state.

I don't think I'm contradicting that idea.
The asynch reset gives you a starting
point for simulation. After this, well-designed
control logic will use an idle state for
specific synchronous initialization.

You're right, Mike; the async reset is helpful for simulation. Looking
back at my recent designs, I see a pattern. All of my state machines
have a safe reset state. A slow reset (where some of the state flops
reset before others) on a one-hot machine decodes as an illegal state
so the machine automatically bounces to the reset state. Once
everything is reset then the machine synchronously transitions to an
"idle" state where it stays until other logic tells it to do something
interesting.

For things like loadable registers, the power-on reset is helpful, and
the usual template of

myreg : process (clk, reset) is
begin
if (reset = '1') then
register <= INITVAL;
....

tells the synthesis tool to use INITVAL as the power-on default as well
as the async reset value. Ususally the rest of the logic doesn't
depend on these values, and the registers are loaded before they're
used.

-a

 

[Symon]

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:3u9tgiFv35pmU1@individual.net...

The asynch reset gives you a starting
point for simulation. After this, well-designed
control logic will use an idle state for
specific synchronous initialization.

Mike, All,

Yep. I use the same template as you. Every process has the same async reset
and is used *only* in functional simulation. Startup in real life is taken
care of by the FF initialisation on configuration. Any extra resets needed
after startup are synchronous.
The exceptions are when I want to infer SRLUTs, distributed RAM etc. In this
case the template misses out the async reset, as it is not supported by the
hardware.
Cheers, Syms.

 

[Totally_Lost]

fpga editor is an interesting tool to explore the internal resources of
each family.

 

[JustJohn]

Lasse wrote:

How about using a bufgce instead of a bufg and gate off the clock
during and sometime after async reset?

Can be done with care, but there's a chorus of "don't gate clocks in an
FPGA" as a general design practice.

See e.g. http://tinyurl.com/73st2 for an answer record containing the
caveat:

"CE must not change during a short setup window just prior to the
rising clock edge on the BUFGCE input I. Violating this setup time
requirement can result in an undefined runt pulse output."

The list of "ways to do it wrong" is far larger than "ways to do it do
it right", and even the do it right list can have some ways to do it
wrong as a subset.

 

[Noway2]

I "normally" use Altera devices. I have a personal preference for them
over Xilinx in addition to a poor technical experience with their
XC9500 series PLDS.

I would assume that you are either using a set purchased development
tools or their webpack ISE. EIther one should have a synthesis step as
part of the compile or build process.

As I indicated, the synthese process converts the VHDL code into a
format applicable to the logic family. The synethesizer must be aware
of the resources available in the device, e.g. how many global clock
buffers are available, or are global resets available, etc.

If you are interested in the nuts and bolts of synthesis, a good place
to start may be in compiler algorithms as this is basically what the
synethizer is.

Hope my explanation helps.

 

Bob,
I also follow that in old Verilog. Thanks to SV, we have enums.
However the OP asked about Post place-and-route sim, hence this trick
won't help much. One needs to build equivalent signal names and enum
mapping. I believe MTI's virtual bus fits the bill better.

Regards
Ajeetha
www.noveldv.com

 

[Bob Perlman]

On 21 Nov 2005 18:33:09 -0800, ajeetha@gmail.com wrote:

Bob,
I also follow that in old Verilog. Thanks to SV, we have enums.
However the OP asked about Post place-and-route sim, hence this trick
won't help much. One needs to build equivalent signal names and enum
mapping. I believe MTI's virtual bus fits the bill better.

Regards
Ajeetha
www.noveldv.com

My mistake--I missed the part about post-place-and-route.

Bob Perlman
Cambrian Design Works

 

[m]

On 21 Nov 2005 13:58:11 -0800, "JustJohn" <john.l.smith@titan.com>
wrote:

My original point is that the place/route tools do not analyse clock
setup and hold paths through an async reset.

Assuming that you're talking about Static Timing Analysis tools (as
opposed to P&R), this is not true in general. Definitely not true for
standard cell flows and even in case of FPGA case, if you set the
right parameters, it's not true. You maybe hiding it by not
constraining your external reset pin with the clocks of the flops it
arrives at. You can get around this by driving your async reset input
of flops with a synchronized version of your reset pin. This way your
internal reset signal is sourced by a clock and it is also helpful in
that it reminds you to do this for every clock domain where reset is
used.

 

[Abbs]

hii

As I indicated, the synthese process converts the VHDL code into a
format applicable to the logic family. The synethesizer must be aware
of the resources available in the device, e.g. how many global clock
buffers are available, or are global resets available, etc.

well, the synthesis report mentions everything, how many gclk, slices,
lut's, multipliers.. according to that we have to modify the design.

If you are interested in the nuts and bolts of synthesis, a good place
to start may be in compiler algorithms as this is basically what the
synethizer is.

i dint actually understand by what you said regarding compiler
algorithms ... actually i was thinking of getting an idea the steps
from coding till porting the code in the hardware.. if i can get this
info on net... any material which will explain step by step after the
coding and testing of the code in testbench till porting it on
hardware.

would be very greatful if u can suggest me with any link of a pdf file
that can solve my problem...

thanks
TAKE CARE

 

[backhus]

Abbs schrieb:

...
well, the synthesis report mentions everything, how many gclk, slices,
lut's, multipliers.. according to that we have to modify the design.

...

i dint actually understand by what you said regarding compiler
algorithms ... actually i was thinking of getting an idea the steps
from coding till porting the code in the hardware.. if i can get this
info on net... any material which will explain step by step after the
coding and testing of the code in testbench till porting it on
hardware.

would be very greatful if u can suggest me with any link of a pdf file
that can solve my problem...

Hi Abbs,
if I understand your question right, you are wondering what the
synthesis tool is making out of your source code. And you want to know
this before synthesis, so you can estimate the effects of your source
code on the synthesis result.

Well, there's the IEEE synthesis standard for vhdl (IEEE 1076.6)that
explains in detail what kind of hardware is generated from a
synthesizable statement. This information is not vendor specific, and
the synthsis tools often make use of vendor specific features when
applicable, but it's a good start point.

Another important thing is the setting of the synthesis tools options.
e.g. in XST you can choose how many Clockbuffers should be used and
wether BRAMS schould be used for logic or not and much more. Study these
options and if you are still in doubt about some of your result put that
small part of your project in a separated project and study the efffects
of different coding styles and/or options by looking ath the RTL and
Technology schematics created by the synthesis tool (the 7.1 rtl view
sometimes misses to plot some inverters though) and compare these
results. There's a lot to learn...

have a nice synthesis
Eilert

 

[Simon Peacock]

A/ Forget the ASIC.. Design the FPGA.. then work out how to translate that
into an ASIC. The two are so totally different that if you try to design
for both you will ultimately fail.

B/ The double latch.....

clk_transfer : process (rst, clk) is
begin
if (rst = reset_active_c) then
tmp <= (others => '0');
data_out <= (others => '0');
elsif rising_edge(clk) then
tmp1 <= data_in;
data_out <= tmp1;
end if;
end process clk_transfer;

data_out = data_in after a little delay.
No doubt there will be debate to see if there should be a tmp2. I actually
have a standard block called meta_data and meta_clk which get called..
meta_data is for data signals.. i.e. static lines. meta_clk converts the
incoming signal to an edge which is phase aligned to meta_data.
The above is similar to these two routines.. but I can't guarantee it is
identical as they are at work and I haven't touched the blocks in a number
of years. (So I don't remember what's inside.. just that they work).

C/ See meta clock... I have an E1 card.. it has a 32.768 MHz, 2.048 MHz (E1
ref), 1.5432 MHz (T1 ref), 16.384 MHz, 4 x 2.048 MHz TX clocks and 4 x 2.048
MHz RX clocks. Only the 32.768 MHz and the two references are related...
all the rest are independent... So who said you need lots of clock lines?

Everything is "meta_clk" or "meta_data" up to the 16.384 MHz which is the
bus timing. The 32.768 MHz is used as a stable system reference along with
the E1 & T1 references. Also the 32 MHz is used to calculate the accuracy
of the 4 E1 ports by a simple long duration counter. The counter is
accurate to 1 ppm but the reference is good to 25 ppm. Room temperature
showed about 5-10ppm clock speed error

So ... provided your "reference" is faster than you actually clocks, there
is no problems... just treat all clocks as edge generators which translates
into clock enables.

Simon


"huangjie" <huangjielg@gmail.com> wrote in message
news:1132568034.262632.53520@z14g2000cwz.googlegroups.com...
Thanks for your suggestion !
But first ,how to use "the infamous double latch" ?
second, my asic does not have only one 125M clk, instead it have 5
more ,
and all of them are input from external chip and have no any frequency
or phase
relations.

Simon Peacock ??:

So clock everything at 125 MHz and use clock enables. Then use FIFO's or
the infamous double latch to transfer between the 33MHz and 125Mhz clock
domains.

Simon

"huangjie" <huangjielg@gmail.com> wrote in message
news:1132535246.171569.78800@f14g2000cwb.googlegroups.com...
Unfortunatly,the clock does not slow enough,eg, one at 125M,pci at
33MHZ.
Since they are interface to other device they can't slow down.

 

[Simon Peacock]

If the Xilinx widow is minimized.. you should notice the window you are
working in become responsive again
pop up windows are a strict no no.. Protel hates them, I have also had them
pop up behind other windows... if you happen to click at the wrong time...
or you just press return as the window pops up..

Simon


"Gabor" <gabor@alacron.com> wrote in message
news:1132584267.548807.155370@f14g2000cwb.googlegroups.com...

Fred wrote:
"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
news:dlskc7$610$1@news.datemas.de...
On a sunny day (Mon, 21 Nov 2005 12:48:13 -0000) it happened "Fred"
fred@nowhere.com> wrote in
4381c20e$0$23287$db0fefd9@news.zen.co.uk>:

I find it frustrating that there is no way or telling if a compilation
has
ended or not. I can't find any feature in ISE which makes a sound
when
it's
finished. I am aware that some might find this an annoying feature
but
would save me periodically checking to see if it's finished or come to
an
end early due to a mistake.

Any ideas?
I'd think that hanging a themocouple with level detector on the
processor,
or heat exhaust, was a nice lunch 'time project ;-)

In Linux you could use grep or awk on the output of 'top':

CPU states: 0.5% user, 2.7% system, 15.4% nice, 81.1% idle

look for > X percentage idle, and use keyboard beep:
echo -e "\a"

....


A utility to see if a file had been modified would be a possible method.

I usually start the build by double-clicking "Generate PROM, ACE, or
JTAG File"
which will pop up an iMPACT window when finished. Sound would be
nicer, though
because I'm usually typing something when the window pops up and takes
over
the focus...

 

[Simon Peacock]

there are async resets ... and async resets...

In all the designs at work async resets are used throughout... except, as
has been pointed out, where the result of the flip flop can be guaranteed
after a few clock cycles. Where few is a debatable number.
There is a big BUT to this... if the clock is continuous, then the async
reset actually comes from a reset synchroniser, that is the clock using the
reset generates the reset. If the clock is gapped (e.g. SPI clock) then the
reset is async. And yes... there is one reset per clock line.

My preference is to use the double latch system ... "rst_in" clears both
latches and one latch cascades into the other.. shift register style... the
result is the reset for that clock.


Simon


"Andy Peters" <Bassman59a@yahoo.com> wrote in message
news:1132594075.241306.92660@g47g2000cwa.googlegroups.com...

Mike Treseler wrote:
Hal Murray wrote:
I thought that consensus here was to use the global
reset hardware to (asynchronously) force your state
machines into a known state and then use a local
FF that has been synchronized to get out of that state.

I don't think I'm contradicting that idea.
The asynch reset gives you a starting
point for simulation. After this, well-designed
control logic will use an idle state for
specific synchronous initialization.

You're right, Mike; the async reset is helpful for simulation. Looking
back at my recent designs, I see a pattern. All of my state machines
have a safe reset state. A slow reset (where some of the state flops
reset before others) on a one-hot machine decodes as an illegal state
so the machine automatically bounces to the reset state. Once
everything is reset then the machine synchronously transitions to an
"idle" state where it stays until other logic tells it to do something
interesting.

For things like loadable registers, the power-on reset is helpful, and
the usual template of

myreg : process (clk, reset) is
begin
if (reset = '1') then
register <= INITVAL;
....

tells the synthesis tool to use INITVAL as the power-on default as well
as the async reset value. Ususally the rest of the logic doesn't
depend on these values, and the registers are loaded before they're
used.

-a

 

[johnp]

All -

Of course, I realize that my code sample REALLY wants to map to the
Enable pin:
always @(posedge clk)
if (condition)
sig4 <= sig3;

The suggestion to recode the Verilog to look like:
always @(posedge clk)
sig4 <= (sig1 & ~sig2) ? sig3 : sig4;

concerns me since a smart synthesizer would recognize this to be
EXACTLY
the sime code, just written in an odd way.

The safest approach (which I've change to) is to add another level of
pipelining.

It just seems sad that even when the LUTs are available, the
synthesizer put
in an extra logic level so it could use the Enable pin.

BTW, this is with XST 6.2.03. It could be that the newer versions are
better.

John Providenza

 

[Brad Smallridge]

And then there is this:

cam1_dcmfx2 : dcmfx2
port map(
clkin_n_in => gpio_exp_hdr2(6), -- cam1_xclk,
clkin_p_in => gpio_exp_hdr2(7), -- cam1_xclk,
rst_in => reset,
clkfx_out => cam1_clk7x,
clkin_ibufgds_out => open,
clk0_out => cam1_xclk,
locked_out => cam1_lock7x );

generated clock with external differential inputs selected

 

[Brad Smallridge]

And this:

cam1_dcmfx2 : dcmfx2
port map(
clkin_n_in => gpio_exp_hdr2(6), -- cam1_xclk,
clkin_p_in => gpio_exp_hdr2(7), -- cam1_xclk,
rst_in => reset,
clkfx_out => cam1_clk7x,
clkin_ibufgds_out => open,
clk0_out => cam1_xclk,
locked_out => cam1_lock7x );

 

[Austin Lesea]

Nick,

I assume that Cyclone works similarly to our own FPGAs in that all flip
flops are inti tally set to 0 by the house-cleaning (initialization
prior to configuration) at power on.

You can check this by reading their manual on what happens during power
on and configuration.

Then, during configuration, the state of the flip flops for logic may
(or may not) be set, or reset to a state as specified by the bitstream
(depends on the device, and its options when being configured).

If you have designed the state machine with no hidden states, and in
such a way that it will always return to a known state given a set of
good inputs, there is no need for a reset.

In the case of a 1-hot state machine (very popular in FPGAs) this also
means that detection of having more than one state set (more than one
flip flop) must decode and send you back to a known state of having only
one state active!

Austin

Nick wrote:

Hello,

I'm in the final phase of a design in VHDL on a Cyclon, and i am
really puzzled by something.
I do not have an external reset pin, so how can i ensure that my
states machines start at the right state, that all values are well
initialized and everything ?

It seems to work as it is now, but i couldn't find any litterature on
this subject.

Many thanks
Nick

 

[Duane Clark]

johnp wrote:

All -

Of course, I realize that my code sample REALLY wants to map to the
Enable pin:
always @(posedge clk)
if (condition)
sig4 <= sig3;

The suggestion to recode the Verilog to look like:
always @(posedge clk)
sig4 <= (sig1 & ~sig2) ? sig3 : sig4;

concerns me since a smart synthesizer would recognize this to be
EXACTLY the sime code, just written in an odd way.

That would require that the synthesis tool specifically look for the
default value on the right be the same signal as is being assigned to.
While I suppose it is possible that a synthesis tool might do that, I
kind of doubt it. That would seem to me to require that the tool
designer deliberately coded the tool to de-optimize (is that a word
the code.

 

[huangjie]

I have understood your idea, and know why yours work but mine cann't .
Just because your slow clock is slow ,and mine is very fast.
How can I deal with 125M clocks just as it is 2M ? How fast my
"reference" for 125M ?
Perhaps I can use a group of some phase-shift clocks to get a clk
enable signals.
Thank you again!