Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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: 155702On 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
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: 155704On 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 ? -jgArticle: 155705
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.comArticle: 155706
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. -- glenArticle: 155707
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 EilertArticle: 155708
>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: 155709Hi,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.comArticle: 155710
>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.comArticle: 155711
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
>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.comArticle: 155713
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. -- GaborArticle: 155714
>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.comArticle: 155715
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. -- GaborArticle: 155716
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.deArticle: 155717
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
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. -- glenArticle: 155719
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. AndyArticle: 155720
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, MarkArticle: 155721
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... ;) -- RickArticle: 155722
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. AndyArticle: 155723
Rick, You might add MicroSemi Igloo2 to your list as well. A SmartFusion2 without the ARM, but still has the other hard-silicon interfaces. AndyArticle: 155724
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:
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