Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 155700

Article: 155700
Subject: Re: [cross-post] vlib, vmap, vcom, how it all works...
From: alb <alessandro.basili@cern.ch>
Date: Sat, 10 Aug 2013 01:30:07 +0200
Links: << >>  << T >>  << A >>
On 09/08/2013 09:04, goouse99@gmail.com wrote:
[]
>> What is strange is the use of a test.do script which may severely
>> affect everything since I can ran whatever command in a do
>> script... I'm not sure how much I want to depend on that.
[]
> you seem to make things much more complicated than they are.

if you refer to the quoted text above then I may have lots of reasons
not to depend on a script that may interfere with my previously compiled
code. Placing compiler options in two separate scripts can
be confusing and IMO prone to errors. There should always be 'one source
of truth'! :-)

> 
> Some simple hints: To start modelsim from th ecommandline: vsim -do
> myscript.do

I'm interested in starting vsim in batch mode. Since I'm controlling my
flow with a makefile I tend to refrain from scattering my options around.

> 
> The -L option in vsim is for verilog simulations only, isn't it? You
> might let it away, unless you don't do mixed mode simulations.

from the reference manual:
-L <library_name> …
(optional) Specifies the library to search for design units instantiated
from Verilog and for VHDL default component binding. Refer to “Library
Usage” for more information. If multiple libraries are specified, each
must be preceded by the -L option. Libraries are searched in the order
in which they appear on the command line.

> If you don't explicitly mention an architecture in a vsim command,
> the first one is taken from the library. Testbenches mostly have just
> one architecture anyway.

I may have several architectures for several testcases (even though this
is not my preferred way). And any way, it seems I can pass either the
configuration or the entity/architecture pair as object arguments.
BTW, quoting the reference manual:

"The entity may have an architecture optionally specified; if omitted
the last architecture compiled." (not the first).

> When you create a local library, no vmap is needed. vlib my_library 
> is sufficient.

interesting. Does it mean that vcom looks always for the current
directory to look for libraries?

> Also this can be done just once, because as you already have seen it
> is stored in the ini file.

if no vmap is used than the library is not stored in the ini file. I did
a quick check: remove modelsim.ini from current directory, run vlib
mylib, no ini file created.

> If you are using libraries more often, like the vendor libraries, you
> should put them in a higher level ini file, so they are present for
> all your projects. (Ini files are read in beginning from the modelsim
> install path, then the users home dir and finally the project dir.
> The first one is global but can be partly overwritten by the later
> ones)

that's an interesting point. I got the impression that when using vmap
the first time a modelsim.ini was added to the local directory from the
modelsim install path and then modified accordingly.

[]
> By the way, behavioral simulation (presyn) and timing simulation
> (post-par) make sense. What's the benefit of a post-syn simulation? 
> Is it just to distinguish synthesis tool bugs from design bugs?

Actually, if I'm happy with my postsynth simulation I may skip the
post-par, provided that static timing analysis doesn't report any
violation. What else do you expect from your post-par simulation?
I still might be missing the point, but I do not see what is the benefit
of a post-par simulation (even though I included it in my workflow in
the OP).


Article: 155701
Subject: Re: [cross-post] vlib, vmap, vcom, how it all works...
From: alb <alessandro.basili@cern.ch>
Date: Sat, 10 Aug 2013 01:53:40 +0200
Links: << >>  << T >>  << A >>
Hi Robert,

On 09/08/2013 11:38, RCIngham wrote:
[]
>>> In your script which performs compilation you may want to include code
> to
>>> delete-and-reinitialise libraries to ensure that you are using only the
>>> latest code, for instance something like:
>>>
>>> if { [file exists test] } {
>>>   vdel -lib test -all
>>> }
>>> vlib -long test
>>> vmap test test
>>
>> Uhm, I thought that bringing the project up-to-date was done by make,
>> simply checking at the files' timestamps. I understand that make cannot
>> guarantee that vcom does not write properly the 'object' in the library,
>> therefore your suggestion might be on the safe side. The only issue with
>> this approach is that I would need to recompile every time the whole
>> library.
> 
> If you want to use 'make' (or 'vmake') I cannot assist further. We don't
> use it here. Formal synthesis builds are ALWAYS done from scratch, and I
> suspect that formal verification is similar.

I still do not grasp the reason behind compiling everything from
scratch. VHDL has clear dependencies and if you take care (as with a
makefile) about bringing all the dependencies up to date, why should you
synthesize everything again?

If we agree that a synthesis is a repeatable process, i.e. for a given
source of code+constraints it will always result in the same logic, then
I do not understand the need for building from scratch. If my assumption
is not the same, then again I wouldn't recompile something if I know it
works (if ain't broken don't fix it!).


Article: 155702
Subject: Re: [cross-post] vlib, vmap, vcom, how it all works...
From: francesjaynetaylor@gmail.com
Date: Sat, 10 Aug 2013 09:32:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, 10 August 2013 00:30:07 UTC+1, alb  wrote:

>=20
> Actually, if I'm happy with my postsynth simulation I may skip the
>=20
> post-par, provided that static timing analysis doesn't report any
>=20
> violation. What else do you expect from your post-par simulation?
>=20
> I still might be missing the point, but I do not see what is the benefit
>=20
> of a post-par simulation (even though I included it in my workflow in
>=20
> the OP).

Last time I looked, Altera and XIlinx take different approaches to timing s=
imulation. Altera docs say FPGA designs are getting too large and timing si=
mulations take too long, so altera has dropped support for timing simulatio=
ns for its newer devices, and their docs state that you should use STA. Xil=
inx docs iirc state that timing simulation should be done because you can't=
 rely solely on STA for their FPGAs.

I don't know what Actel recommends.

Article: 155703
Subject: Re: [cross-post] vlib, vmap, vcom, how it all works...
From: francesjaynetaylor@gmail.com
Date: Sat, 10 Aug 2013 09:49:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, 10 August 2013 00:53:40 UTC+1, alb  wrote:
> =20
> On 09/08/2013 11:38, RCIngham wrote:
>=20
> []
>=20
> >>> In your script which performs compilation you may want to include cod=
e
>=20
> > to
>=20
> >>> delete-and-reinitialise libraries to ensure that you are using only t=
he
>=20
> >>> latest code, for instance something like:
>=20
> >>>
>=20
> >>> if { [file exists test] } {
>=20
> >>>   vdel -lib test -all
>=20
> >>> }
>=20
> >>> vlib -long test
>=20
> >>> vmap test test
>=20
> >>
>=20
> >> Uhm, I thought that bringing the project up-to-date was done by make,
>=20
> >> simply checking at the files' timestamps. I understand that make canno=
t
>=20
> >> guarantee that vcom does not write properly the 'object' in the librar=
y,
>=20
> >> therefore your suggestion might be on the safe side. The only issue wi=
th
>=20
> >> this approach is that I would need to recompile every time the whole
>=20
> >> library.
>=20
> >=20
>=20
> > If you want to use 'make' (or 'vmake') I cannot assist further. We don'=
t
>=20
> > use it here. Formal synthesis builds are ALWAYS done from scratch, and =
I
>=20
> > suspect that formal verification is similar.
>=20
>=20
>=20
> I still do not grasp the reason behind compiling everything from
>=20
> scratch. VHDL has clear dependencies and if you take care (as with a
>=20
> makefile) about bringing all the dependencies up to date, why should you
>=20
> synthesize everything again?
>=20
>=20
>=20
> If we agree that a synthesis is a repeatable process, i.e. for a given
>=20
> source of code+constraints it will always result in the same logic, then
>=20
> I do not understand the need for building from scratch. If my assumption
>=20
> is not the same, then again I wouldn't recompile something if I know it
>=20
> works (if ain't broken don't fix it!).

Generally for consistancy in formal verification you build from scratch, ru=
n simulation, analyse results. Buggy build scripts are not _that_ uncommon.=
 Also if you're only checking timestamps, what happens when you change buil=
d options, do all your files get recompiled?

That's not to say you should take this approach with your projects. It depe=
nds on the nature of your project.

Article: 155704
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: jg <j.m.granville@gmail.com>
Date: Sun, 11 Aug 2013 01:53:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, July 31, 2013 6:37:21 AM UTC+12, rickman wrote:
>It has 3000 LUTs which are around 80% used and the internal 
> configuration Flash saves space on the tiny, cramped board.
> 
> Mostly the alternatives are other Lattice devices, but none are a 
 >perfect fit.  XP2, XO2 and the iCE40 line.  The ones that come in the 
> same package don't have as many LUTs, only 2100 which would require 
> using a soft CPU to implement the slow functions in fewer LUTs. 

Someone mentioned Altera has a new family coming shortly, above the MAX V, which is looking backward next to Lattice.
So you could push them for more info on what packages/sizes they plan ?

-jg

Article: 155705
Subject: Is a block spoof IP filter in hardware is required
From: "pini_kr" <93490@embeddedrelated>
Date: Sun, 11 Aug 2013 12:45:29 -0500
Links: << >>  << T >>  << A >>
IP TTL spoofed packet block in hardware

I read recently, that some linux kernels have the ability to block spoofed
packets. Some hackers attack servers by sending many packets. They also put
some fake data in the offending packets. The arrival of multiple packets,
with a well known source IP, in the spoofed packet, causes many interrupts
in the server. This, in the best case, results with a degraded performance.
Some kernels try to counter attack with an IP TTL block spoofed filter. I
have decided to build such a filter in hardware. It would try to do the job
in hardware, therefor offloads the kernel from this job. The idea is to
have two main states in hardware machine, per each incoming IP namely:
learning and check. In the former the hardware machine will build a table,
per each incoming source IP, where it will average the TTL values of the
packet. Once a programmable number of TTL values, for a given packet, have
been studied, the hardware machine switches to check mode. During check
mode, if a packet arrives and its TTL is outside an allowable range, a
block packet indication is set. Such an implementation requires memory.
With the way the design is implemented any memory smaller than 32 bits
addressable, for IPV4, can be used.

Is a block spoof IP filter in hardware is required? Please let me know what
you think.



	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155706
Subject: Re: Is a block spoof IP filter in hardware is required
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 12 Aug 2013 03:52:17 +0000 (UTC)
Links: << >>  << T >>  << A >>
pini_kr <93490@embeddedrelated> wrote:
> IP TTL spoofed packet block in hardware
 
> I read recently, that some linux kernels have the ability to block spoofed
> packets. Some hackers attack servers by sending many packets. They also put
> some fake data in the offending packets. The arrival of multiple packets,
> with a well known source IP, in the spoofed packet, causes many interrupts
> in the server. This, in the best case, results with a degraded performance.
> Some kernels try to counter attack with an IP TTL block spoofed filter. I
> have decided to build such a filter in hardware. It would try to do the job
> in hardware, therefor offloads the kernel from this job. 

Since thisis comp.arch.fpga, seems like adding an FPGA to the
appropriate part of a network card could allow one to program the
appropriate filtering.

That is, you don't have to know now what to do, but allow those
using it to do it.

I am not so sure how hard it is to add FPGA-style logic to an ASIC.
Seems like that would also be useful.

-- glen

Article: 155707
Subject: Re: [cross-post] vlib, vmap, vcom, how it all works...
From: goouse99@gmail.com
Date: Mon, 12 Aug 2013 01:09:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi Al

Am Samstag, 10. August 2013 01:30:07 UTC+2 schrieb alb:
> On 09/08/2013 09:04, goo...@mail... wrote:
>=20
> []
>=20
> >> What is strange is the use of a test.do script which may severely
> >> affect everything since I can ran whatever command in a do
> >> script... I'm not sure how much I want to depend on that.
>=20
As I understand, test.do is getting created automatically by some tool.
So why do you use it anyway if you already have your own scripts and a make=
file (as you mention later).
Just copy/paste the few things you think that might be useful in your own s=
cript and ignore the other one.

> []
>=20
> > you seem to make things much more complicated than they are.
>=20
> if you refer to the quoted text above then I may have lots of reasons
> not to depend on a script that may interfere with my previously compiled
> code. Placing compiler options in two separate scripts can
> be confusing and IMO prone to errors. There should always be 'one source=
=20
> of truth'! :-)
>=20
I agree. But you are in controll of the files, so why are you bothered by t=
he second script. Just leave it away.

> >=20
>=20
> > Some simple hints: To start modelsim from the commandline: vsim -do
> > myscript.do
>=20
> I'm interested in starting vsim in batch mode. Since I'm controlling my
> flow with a makefile I tend to refrain from scattering my options around.
>=20
Ok, I got that wrong. Thought you just wanted to start vsim from batch, but=
 missed that you also want to run it without the GUI appearing.

The documentation about this kind of batch mode states that you simply use =
i/o redirection for this purpose.

vsim tb_name <infile(.do) >outfile


>=20
> > The -L option in vsim is for verilog simulations only, isn't it? You
> > might let it away, unless you don't do mixed mode simulations.
>=20
> from the reference manual:
> -L <library_name> =85
> (optional) Specifies the library to search for design units instantiated
> from Verilog and for VHDL default component binding. Refer to =93Library
> Usage=94 for more information. If multiple libraries are specified, each
> must be preceded by the -L option. Libraries are searched in the order
> in which they appear on the command line.
>=20
I see. Seems like I never  needed the default binding stuff, so I never cam=
e across using -L with my VHDL Testbenches. Maybe Actel handles things diff=
erently.

>=20
> > If you don't explicitly mention an architecture in a vsim command,
> > the first one is taken from the library. Testbenches mostly have just
> > one architecture anyway.
>=20
>=20
> I may have several architectures for several testcases (even though this
> is not my preferred way). And any way, it seems I can pass either the
> configuration or the entity/architecture pair as object arguments.
> BTW, quoting the reference manual:

As you say for yourself, it's not your prefered way. I just wanted to point=
 out that the automatic generated script worked on such an assumption. Mayb=
e the programmer was just lazy.
Of course it is always better to tell the tool specifically which entity an=
d architecture to use. Either directly or via the configuration.

> "The entity may have an architecture optionally specified; if omitted
> the last architecture compiled." (not the first).
Thanks for looking this up.
In any way, if one just names the entity and has several architectures, the=
 tool might use the wrong one. So the assumption (only one arc. per tb) mad=
e by the Actel tool programmers is kind of careless and might only work wit=
hin the world of their own flow.=20

>=20
>=20
> > When you create a local library, no vmap is needed. vlib my_library=20
> > is sufficient.
>=20
>=20
> interesting. Does it mean that vcom looks always for the current
> directory to look for libraries?
>=20
vcom will look up the lib pathes from the ini file and (as wee will see bel=
ow) from the current directory too.

Actually vlib does not just take the name of a new library, but also the pa=
th.
So=20
  vlib my_lib
really means
  vlib ./my_lib
.
Therefore you can also create libraries elsewhere, rather than just the loc=
al directory.
Like
  vlib ~/somwhere/below/your/homedir/my_other_lib

vmap is mainly needed to switch between several versions of the same librar=
y. E.g. if some tool changes or updates require this. But it's a rare occas=
ion.

>=20
> > Also this can be done just once, because as you already have seen it
> > is stored in the ini file.
>=20
> if no vmap is used than the library is not stored in the ini file. I did
> a quick check: remove modelsim.ini from current directory, run vlib
> mylib, no ini file created.
>=20
I did that test too, and found out that even vmap does not create a local i=
ni file. It tries to access those in the modelsim install path. So, apart f=
rom the informations stored in the ini file modelsim seems to be able to fi=
nd libraries in the local directory all by itself.=20
While
  vlib nixus
will be recognized in vsim,
  vlib ../nullus
won't appear in the library list since it is placed in the parent directory=
.
Here a vmap or a manual entry to the ini file (e.g. in case of write protec=
tion by the admin) is needed.   =20

Never had problems to access some local libraries once they were created an=
d you really don't want your work library path always get updated in your m=
ain ini file. Just imagine what would happen on a multi user system with a =
central installation (were that file will be write protected anyway) .


>=20
> > If you are using libraries more often, like the vendor libraries, you
> > should put them in a higher level ini file, so they are present for
> > all your projects. (Ini files are read in beginning from the modelsim
> > install path, then the users home dir and finally the project dir.
> > The first one is global but can be partly overwritten by the later
> > ones)
>=20
>=20
> that's an interesting point. I got the impression that when using vmap
> the first time a modelsim.ini was added to the local directory from the
> modelsim install path and then modified accordingly.
That too, to give you some kind of template.
Still, even if you have no local ini file, modelsim knows all the library p=
athes when you start it. Guess from where, and don't forget that there is a=
 ~/modelsim.ini too.=20
>=20
(Besides, using vmap does not create some local ini file when I use it. But=
 this may be a version or installation specific difference if you happen to=
 see that behavior.)
>=20
> []
>=20
> > By the way, behavioral simulation (presyn) and timing simulation
> > (post-par) make sense. What's the benefit of a post-syn simulation?=20
> > Is it just to distinguish synthesis tool bugs from design bugs?
>=20
> Actually, if I'm happy with my postsynth simulation I may skip the
> post-par, provided that static timing analysis doesn't report any
> violation. What else do you expect from your post-par simulation?
> I still might be missing the point, but I do not see what is the benefit
> of a post-par simulation (even though I included it in my workflow in
> the OP).
That didn't answer the question about the benefit of the postsynth simulati=
on.

From some followup posts and other threads I know that the use of a timing =
simulation is under discussion. Mainly because of the long time it may take=
 for a large design.
STA gives you some valuable informations almost instantly, but it depends o=
n the assumption that your timing constraints are correct and complete.
It analyses the DUTs properties against their specs/constraints.
Still it does not tell how the DUT interacts with the external world.
An accurate timing simulation requires also the tb to do some kind of board=
 level simulation. No easy task, indeed. But the only way to check for inte=
rface problems between DUT and external devices before actually touching re=
al hardware.
It may be good to do at least some tests of the external interfaces rather =
than simulation the whole design with post-par simulations.


Have a nice simulation

  Eilert

Article: 155708
Subject: Re: [cross-post] vlib, vmap, vcom, how it all works...
From: "RCIngham" <2161@embeddedrelated>
Date: Mon, 12 Aug 2013 04:24:27 -0500
Links: << >>  << T >>  << A >>
>Hi Robert,
>
>On 09/08/2013 11:38, RCIngham wrote:
>[]
>>>> In your script which performs compilation you may want to include
code
>> to
>>>> delete-and-reinitialise libraries to ensure that you are using only
the
>>>> latest code, for instance something like:
>>>>
>>>> if { [file exists test] } {
>>>>   vdel -lib test -all
>>>> }
>>>> vlib -long test
>>>> vmap test test
>>>
>>> Uhm, I thought that bringing the project up-to-date was done by make,
>>> simply checking at the files' timestamps. I understand that make
cannot
>>> guarantee that vcom does not write properly the 'object' in the
library,
>>> therefore your suggestion might be on the safe side. The only issue
with
>>> this approach is that I would need to recompile every time the whole
>>> library.
>> 
>> If you want to use 'make' (or 'vmake') I cannot assist further. We
don't
>> use it here. Formal synthesis builds are ALWAYS done from scratch, and
I
>> suspect that formal verification is similar.
>
>I still do not grasp the reason behind compiling everything from
>scratch. VHDL has clear dependencies and if you take care (as with a
>makefile) about bringing all the dependencies up to date, why should you
>synthesize everything again?
>
>If we agree that a synthesis is a repeatable process, i.e. for a given
>source of code+constraints it will always result in the same logic, then
>I do not understand the need for building from scratch. If my assumption
>is not the same, then again I wouldn't recompile something if I know it
>works (if ain't broken don't fix it!).
>

A key word here is 'formal', meaning that the resultant will be used for
anything other than an informal engineering experiment. And 'from scratch'
includes getting the files from the code repository, to ensure that you
know which version of files are being used. We do safety-critical stuff
here, so this is important. YMMV.

However, these days it takes but a few seconds to recompile all the files
for a moderate-to-large-sized simulation, so what's not to like?
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155709
Subject: [HELP]problem with asynchronous fifo ip
From: "zl502593045" <98308@embeddedrelated>
Date: Mon, 12 Aug 2013 20:18:15 -0500
Links: << >>  << T >>  << A >>
Hi,all,
I have some problem and I need help.I am using fifo ip core of spartan
3a.The write clk is 125MHz.I set read enable <= !empty.When I use read clk
with 100MHz, it can read data from fifo correctly and continuously because
write clk >read clk.But when I use 150MHz as the read clk, the data read
from fifo is wrong.The read valid is discontinuously because  write clk <
read clk.
   My question is the problem comes due to the 150MHz is too fast for
spartan 3a or the method using read enable <= !empty is irrationally?
   Thank you very much!

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155710
Subject: Re: [HELP]problem with asynchronous fifo ip
From: "RCIngham" <2161@embeddedrelated>
Date: Tue, 13 Aug 2013 04:41:48 -0500
Links: << >>  << T >>  << A >>
>Hi,all,
>I have some problem and I need help.I am using fifo ip core of spartan
>3a.The write clk is 125MHz.I set read enable <= !empty.When I use read
clk
>with 100MHz, it can read data from fifo correctly and continuously
because
>write clk >read clk.But when I use 150MHz as the read clk, the data read
>from fifo is wrong.The read valid is discontinuously because  write clk <
>read clk.
>   My question is the problem comes due to the 150MHz is too fast for
>spartan 3a or the method using read enable <= !empty is irrationally?
>   Thank you very much!
>

How are you observing this?

Are you simulating (or have you simulated) it?
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155711
Subject: [HELP]problem with asynchronous fifo ip
From: Chris <catalsma@gmail.com>
Date: Tue, 13 Aug 2013 05:14:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
You need to be careful with the asynchronous fifos in general.  I am workin=
g on an artix7 design right now where I thought I could use an asynchronous=
 fifo as a rate buffer but that turned out to be an epic fail.  It worked b=
eautifully in the sim but erratically in the actual hardware.  The asynchro=
nous FIFO does not simulate accurately so do not trust your sim.  I ended u=
p changing the FIFO to synchronous and handling the asynchronous portion ou=
tside the FIFO and everything works beautifully.

I *think* your attempt to use the FIFO empty to gate your read enable makes=
 sense as long as you are clocking it with the read clock.  I can imagine t=
his may sim okay but fail in the lab. =20

My suggestion is to switch to a synchronous FIFO and handle the asynchronou=
s data outside of the FIFO.  If you have to use the FIFO for asynchronous b=
uffering then maybe you could set a guard of written data, ie only read if =
the read data count is greater than five.... That should give you a buffer =
to avoid any reads of an empty fifo.

Article: 155712
Subject: Re: [HELP]problem with asynchronous fifo ip
From: "RCIngham" <2161@embeddedrelated>
Date: Tue, 13 Aug 2013 07:42:03 -0500
Links: << >>  << T >>  << A >>
>You need to be careful with the asynchronous fifos in general.  I am
workin=
>g on an artix7 design right now where I thought I could use an
asynchronous=
> fifo as a rate buffer but that turned out to be an epic fail.  It worked
b=
>eautifully in the sim but erratically in the actual hardware.  The
asynchro=
>nous FIFO does not simulate accurately so do not trust your sim.  I ended
u=
>p changing the FIFO to synchronous and handling the asynchronous portion
ou=
>tside the FIFO and everything works beautifully.
>
>I *think* your attempt to use the FIFO empty to gate your read enable
makes=
> sense as long as you are clocking it with the read clock.  I can imagine
t=
>his may sim okay but fail in the lab. =20
>
>My suggestion is to switch to a synchronous FIFO and handle the
asynchronou=
>s data outside of the FIFO.  If you have to use the FIFO for asynchronous
b=
>uffering then maybe you could set a guard of written data, ie only read if
=
>the read data count is greater than five.... That should give you a buffer
=
>to avoid any reads of an empty fifo.
>

There used to be a problem with the Xilinx CoreGen simulation models for
the Asynchronous FIFOs. The behavioural models were slightly wrong (and
therefore mostly useless). The structural models were correct, so that is
what we always used. They might have fixed the problem, but I wouldn't risk
it!
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155713
Subject: Re: [HELP]problem with asynchronous fifo ip
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 13 Aug 2013 09:19:38 -0400
Links: << >>  << T >>  << A >>
RCIngham wrote:
> There used to be a problem with the Xilinx CoreGen simulation models for
> the Asynchronous FIFOs. The behavioural models were slightly wrong (and
> therefore mostly useless). The structural models were correct, so that is
> what we always used. They might have fixed the problem, but I wouldn't risk
> it!

For some versions of FIFO, the behavioral models were seriously broken.

They were not cycle accurate.

They often failed to model optional flags like programmable full/empty.

They did not correctly model depth (read count, write count) outputs.

However getting back to the original question, if you use the "standard"
FIFO then you need to remember that data is valid on the output one
cycle after you assert read enable.  If you don't account for this it
can appear as if there are data errors every time the FIFO is allowed
to go empty.  If you want to use the data on the same cycle as you apply
read enable, then you should generate the FIFO in "First-word
fall-through (FWFT)" mode.

Other than that, my experience is that these FIFO's work quite well
in hardware as long as your design meets timing.

-- 
Gabor

Article: 155714
Subject: Re: [HELP]problem with asynchronous fifo ip
From: "RCIngham" <2161@embeddedrelated>
Date: Wed, 14 Aug 2013 03:25:41 -0500
Links: << >>  << T >>  << A >>
>RCIngham wrote:
>> There used to be a problem with the Xilinx CoreGen simulation models
for
>> the Asynchronous FIFOs. The behavioural models were slightly wrong (and
>> therefore mostly useless). The structural models were correct, so that
is
>> what we always used. They might have fixed the problem, but I wouldn't
risk
>> it!
>
>For some versions of FIFO, the behavioral models were seriously broken.
>
>They were not cycle accurate.
>
>They often failed to model optional flags like programmable full/empty.
>
>They did not correctly model depth (read count, write count) outputs.
>
>However getting back to the original question, if you use the "standard"
>FIFO then you need to remember that data is valid on the output one
>cycle after you assert read enable.  If you don't account for this it
>can appear as if there are data errors every time the FIFO is allowed
>to go empty.  If you want to use the data on the same cycle as you apply
>read enable, then you should generate the FIFO in "First-word
>fall-through (FWFT)" mode.
>
>Other than that, my experience is that these FIFO's work quite well
>in hardware as long as your design meets timing.
>
>-- 
>Gabor

I agree that FWFT mode is often useful, and I have used it multiple times.
Even so, it takes several clock cycles for the first written word to 'fall
through', which is why simulation is so important for honing the control
logic.

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 155715
Subject: Re: [HELP]problem with asynchronous fifo ip
From: GaborSzakacs <gabor@alacron.com>
Date: Fri, 16 Aug 2013 14:46:32 -0400
Links: << >>  << T >>  << A >>
RCIngham wrote:
>> RCIngham wrote:
>>> There used to be a problem with the Xilinx CoreGen simulation models
> for
>>> the Asynchronous FIFOs. The behavioural models were slightly wrong (and
>>> therefore mostly useless). The structural models were correct, so that
> is
>>> what we always used. They might have fixed the problem, but I wouldn't
> risk
>>> it!
>> For some versions of FIFO, the behavioral models were seriously broken.
>>
>> They were not cycle accurate.
>>
>> They often failed to model optional flags like programmable full/empty.
>>
>> They did not correctly model depth (read count, write count) outputs.
>>
>> However getting back to the original question, if you use the "standard"
>> FIFO then you need to remember that data is valid on the output one
>> cycle after you assert read enable.  If you don't account for this it
>> can appear as if there are data errors every time the FIFO is allowed
>> to go empty.  If you want to use the data on the same cycle as you apply
>> read enable, then you should generate the FIFO in "First-word
>> fall-through (FWFT)" mode.
>>
>> Other than that, my experience is that these FIFO's work quite well
>> in hardware as long as your design meets timing.
>>
>> -- 
>> Gabor
> 
> I agree that FWFT mode is often useful, and I have used it multiple times.
> Even so, it takes several clock cycles for the first written word to 'fall
> through', which is why simulation is so important for honing the control
> logic.
> 

We seem to have lost the OP along the way, but from the sound of the
problem it had nothing to do with overall latency, which as you say is
the same for "standard" or FWFT FIFO's.  The difference is in the read
latency, and since he has read enable tied to !empty, that's the latency
that you need to look at.  In the "standard" case data is valid one
cycle after !empty going true.  In the FWFT case data is valid on the
same cycle that !empty goes true.  If he's never seeing !empty go false
then it doesn't matter.  If !empty comes and goes, then you get errors
from sampling data too early or too late.

-- 
Gabor

Article: 155716
Subject: Re: seperate high speed rules for HDL?
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Mon, 19 Aug 2013 17:43:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
Your second example will run at half the clock speed of the first example because there only is half a clock from output to input. 
The data gets through two flip-flops per clock so both examples get about the same throughput as a first estimate.
If you look at it in more detail the second example will be slower because clock duty cycle uncertainty now eats into your timing budget.

Also: Use rising_edge(clk) and falling_edge(clk) for safer simulation and better readability compared to clk'event...

Have fun,

Kolja

www.cronologic.de

Article: 155717
Subject: Cascaded floating-point reduction?
From: Saad Zafar <saad1024@gmail.com>
Date: Wed, 21 Aug 2013 12:31:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
y1=3D 1.5f*y0 - x*y0*y0*y0=20

...Note that all quantities are in single precision floating point. I can't=
 write this equation in behavioral form for synthesizer to optimize because=
 it has to be broken down and fed into FP-multipliers. I have got both the =
y0 and x available in 1 clock cycle ready to be plugged into this equation =
...Now I'm stuck on reducing this equation in least cycles...right now I ha=
ve got cascaded series fp-multipliers feeding into final fp-subtractor...Ea=
ch multiplication consuming one clock cycle.

What in your opinion should be the best way to map this equation in hardwar=
e? Is there an alternative form of this equation that would be more suitabl=
e for implementation?

Regards.

Article: 155718
Subject: Re: Cascaded floating-point reduction?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 21 Aug 2013 20:11:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
Saad Zafar <saad1024@gmail.com> wrote:
> y1= 1.5f*y0 - x*y0*y0*y0 

The usual one would be to factor out a y0, so

  y1 = (1.5f-x*y0*y0)*y0;

That sames one multiplier, but maybe the same number of
pipeline stages. 

If you factor it as 1.5f*y0-(x*y0)*(y0*y0);

Then you can do it in one less pipeline stage, but no less
multipliers.

-- glen


Article: 155719
Subject: Re: Cascaded floating-point reduction?
From: jonesandy@comcast.net
Date: Wed, 21 Aug 2013 15:41:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
I think the ieee floating point library's * operator is synthesizable, but synthesis would try to build the fp multipliers out of fixed point multipliers (e.g. DSP blocks) itself, which may take more than one clock cycle.

If the above works, then you could enable retiming & pipelining, and then use your original expression, and run the result through multiple pipeline stages. Retiming/pipelining can redistribute the operations and/or logic among the pipeline stages.

I have seen cases where synthesis tools did this automatically when assembling smaller fixed point multipliers into one larger multiplier, so long as there were pipeline register stages (clock cycles) available to spread across.

Andy 

Article: 155720
Subject: Re: Cascaded floating-point reduction?
From: gtwrek@sonic.net (Mark Curry)
Date: Wed, 21 Aug 2013 23:55:15 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <593a4792-bb97-421a-a338-3f644de0256a@googlegroups.com>,
 <jonesandy@comcast.net> wrote:
>I think the ieee floating point library's * operator is synthesizable, 
>but synthesis would try to build the fp multipliers out of fixed point
>multipliers (e.g. DSP blocks) itself, which may take more than
>one clock cycle.

Not in any synthesizer I know.  Floating point types aren't handled 
at all, much less operation like multiplication on them.
I wouldn't expect them to do so *EVER*.  Too much overhead,
and too little of a customer base would need/want it.

Regards,

Mark


Article: 155721
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: rickman <gnuarm@gmail.com>
Date: Wed, 21 Aug 2013 21:27:58 -0400
Links: << >>  << T >>  << A >>
On 8/11/2013 4:53 AM, jg wrote:
> On Wednesday, July 31, 2013 6:37:21 AM UTC+12, rickman wrote:
>> It has 3000 LUTs which are around 80% used and the internal
>> configuration Flash saves space on the tiny, cramped board.
>>
>> Mostly the alternatives are other Lattice devices, but none are a
>   >perfect fit.  XP2, XO2 and the iCE40 line.  The ones that come in the
>> same package don't have as many LUTs, only 2100 which would require
>> using a soft CPU to implement the slow functions in fewer LUTs.
>
> Someone mentioned Altera has a new family coming shortly, above the MAX V, which is looking backward next to Lattice.
> So you could push them for more info on what packages/sizes they plan ?

Funny, I shot an email to my favorite distie and I was eventually 
connected with an FAE.  He is new to the company and indicated he would 
be digging up an NDA to sign.  I was a bit puzzled by this, it has been 
a while since I was asked to sign an NDA to hear about new products.  I 
didn't hear back after a few days I called him.  He was rather surprised 
I was asking about the new line and asked how I even knew about it.  I 
told him I didn't know much other than it was a follow on to the Max V 
and was pretty new.  Seems it is so new that Altera hasn't spoken about 
it other than under NDA, lol.

What I did get out of him was that currently they are pushing out a new 
Stradix line IIRC and that would occupy them for most of 2014.  If they 
wouldn't have the Max V follow on in production until 2015 that is a bit 
long for me to hold my breath.  So I'm moving on... and I guess we 
aren't doing the NDA... that's what I am required to say, lol

But at least Altera hasn't abandoned the Flash based logic area like 
Xilinx.  I like Lattice, but I'd hate for them to be the last man 
standing in Flash FPGAs, well, other than MicroSemi assuming you count 
them as being in the FPGA business.  Just kidding... ;)

-- 

Rick

Article: 155722
Subject: Re: Cascaded floating-point reduction?
From: jonesandy@comcast.net
Date: Thu, 22 Aug 2013 06:53:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, August 21, 2013 6:55:15 PM UTC-5, Mark Curry wrote:
> Not in any synthesizer I know. Floating point types aren't
> handled at all, much less operation like multiplication on them.
> I wouldn't expect them to do so *EVER*. Too much overhead,
> and too little of a customer base would need/want it.

Mark,

Ok, I checked our FPGA synthesis tool's documentation.

The Synplify Pro reference guide states the following in regards to the bui=
lt-in "real" data type:=20

"When one of the following constructs in encountered, compilation continues=
,
but will subsequently error out if logic must be generated for the construc=
t.

=95 real data types (real data expressions are supported in VHDL-2008 IEEE
float_pkg.vhd) =96 real data types are supported as constant declarations o=
r
as constants used in expressions as long as no floating point logic must
be generated"

Thus, you cannot use the built-in real data type or expressions thereof to =
generate logic.

However, the reference guide also states the following:

"The following packages are supported in VHDL 2008:
=95 fixed_pkg.vhd, float_pkg.vhd, fixed_generic_pkg.vhd, float_generic_pkg.=
vhd,
fixed_float_types.vhd =96 IEEE fixed and floating point packages
...
String and text I/O functions in the above packages are not supported. Thes=
e
functions include read(), write(), to_string()."

Significantly, it states no other limitations on the support for float_pkg.

The float_generic_package (the generic package which float_pkg instantiates=
) defines the "*" operator for type float.

From ieee.float_generic_pkg-body.vhdl, the following indicates that the pac=
kage is synthesizeable:

  -- This deferred constant will tell you if the package body is synthesiza=
ble
  -- or implemented as real numbers, set to "true" if synthesizable.
  constant fphdlsynth_or_real : BOOLEAN :=3D true;  -- deferred constant

So, while I have not tried it to see, it appears that there are at least de=
finite plans, if not the current ability, to synthesize floating point hard=
ware long before *EVER* gets here.

The resulting hardware may not be particularly efficient, and may not be op=
erable in a single clock cycle at any reasonable clock rate, but that is wh=
ere retiming and pipelining come in.

Andy

Article: 155723
Subject: Re: Lattice Announces EOL for XP and EC/P Product Lines
From: jonesandy@comcast.net
Date: Thu, 22 Aug 2013 09:09:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
Rick,

You might add MicroSemi Igloo2 to your list as well. A SmartFusion2 without the ARM, but still has the other hard-silicon interfaces.

Andy

Article: 155724
Subject: Re: Cascaded floating-point reduction?
From: gtwrek@sonic.net (Mark Curry)
Date: Thu, 22 Aug 2013 16:46:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3d527338-9687-41dc-b4ab-a60e7a1bba19@googlegroups.com>,
 <jonesandy@comcast.net> wrote:
>On Wednesday, August 21, 2013 6:55:15 PM UTC-5, Mark Curry wrote:
>> Not in any synthesizer I know. Floating point types aren't
>> handled at all, much less operation like multiplication on them.
>> I wouldn't expect them to do so *EVER*. Too much overhead,
>> and too little of a customer base would need/want it.
>
>Mark,
>
>Ok, I checked our FPGA synthesis tool's documentation.
>
>However, the reference guide also states the following:
>
>"The following packages are supported in VHDL 2008:
>• fixed_pkg.vhd, float_pkg.vhd, fixed_generic_pkg.vhd, float_generic_pkg.vhd,
>fixed_float_types.vhd – IEEE fixed and floating point packages
>...
>String and text I/O functions in the above packages are not supported. These
>functions include read(), write(), to_string()."
>
>Significantly, it states no other limitations on the support for float_pkg.
>
>The float_generic_package (the generic package which float_pkg instantiates)
>defines the "*" operator for type float.
>
>From ieee.float_generic_pkg-body.vhdl, the following indicates that the 
>package is synthesizeable:
>
>  -- This deferred constant will tell you if the package body is synthesizable
>  -- or implemented as real numbers, set to "true" if synthesizable.
>  constant fphdlsynth_or_real : BOOLEAN := true;  -- deferred constant
>
>So, while I have not tried it to see, it appears that there are at least
>definite plans, if not the current ability, to synthesize floating point
>hardware long before *EVER* gets here.
>
>The resulting hardware may not be particularly efficient, and may not be 
>operable in a single clock cycle at any reasonable clock rate, but that is
>where retiming and pipelining come in.
>

Andy, 

I stand corrected.  Being a verilog user - I wasn't familiar with these
updates for VHDL-2008.

Looks like they've done it correctly.  There's default support for IEEE 754
32-bit, and IEEE 754 64-bit.  But users can (and very likely should) use the 
generic float types, specifying all the settings including exponent width, 
fraction width, rounding options, normalization options, etc...  One wonders 
however how exceptions will be handled in synthesis (i.e. NaN, etc.).

The generic 32-bit, (and worse 64-bit) IEEE 754 floating point are rarely EVER 
appropriate for FPGA (and even ASIC) designs.  For both you're almost always 
designing something for a specific problem.  There's not going to be many valid
cases where a specfic wire is going to need all that dynamic range.   For 
generic processors, (and DSPs) yeah, it may be appropriate. 

But more controlled "floating point" like these library's provide, might be 
useful.  I tend to think they'll also be dangerous in the hands of 
inexperienced HW designers - who will just take the defaults and go. 

Thanks for the pointer.

Mark



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search