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
2017JanFebMarApr2017

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 154900

Article: 154900
Subject: Idea Hunt, FPGA + ARM Cortex-M3
From: Shanjit Singh <shanjitsingh@gmail.com>
Date: Sat, 9 Feb 2013 06:53:33 -0800 (PST)
Links: << >>  << T >>  << A >>
I aim to demonstrate the need for FPGAs as compared to MPUs like (e.g. ARM =
Cortex-M3 based from TI/ST) in doing processing intensive stuff. I am looki=
ng for some help in this regard. I want to show that a design based on MPUs=
 + FPGA will be more faster (feasible?).

The following is what i have come up with till now,

Comparing N-Point FFTs
Compare designs based on Cordic
Huge Calculations based on Fixed/Floating points Systems. (ALU Design)
Are there more novel applications where the FPGA + MPU design achieves much=
 more than a single MPU ? It would be great to have some stuff pointed at. =
Happy to read as always :) Thanks.

Article: 154901
Subject: Re: Idea Hunt, FPGA + ARM Cortex-M3
From: jg <j.m.granville@gmail.com>
Date: Sun, 10 Feb 2013 18:43:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On Sunday, February 10, 2013 3:53:33 AM UTC+13, Shanjit Singh wrote:
> I aim to demonstrate the need for FPGAs as compared to MPUs like (e.g. AR=
M Cortex-M3 based from TI/ST) in doing processing intensive stuff. I am loo=
king for some help in this regard. I want to show that a design based on MP=
Us + FPGA will be more faster (feasible?).
>=20
>=20
>=20
> The following is what i have come up with till now,
>=20
> Comparing N-Point FFTs
> Compare designs based on Cordic
> Huge Calculations based on Fixed/Floating points Systems. (ALU Design)
> Are there more novel applications where the FPGA + MPU design achieves mu=
ch more than a single MPU ? It would be great to have some stuff pointed at=
. Happy to read as always :) Thanks.

 You have missed IO response time issues.=20
For items like high precision PWN, or fast protection PWM, or other critica=
l real-time IO, sometimes a small state engine done in Logic, runs rings ar=
ound a SW attempt.
 See Cypress & Actel for offerings of Programmable Logic + CPU.=20
-jg

Article: 154902
Subject: Re: Idea Hunt, FPGA + ARM Cortex-M3
From: Tim Wescott <tim@seemywebsite.please>
Date: Sun, 10 Feb 2013 21:35:29 -0600
Links: << >>  << T >>  << A >>
On Sat, 09 Feb 2013 06:53:33 -0800, Shanjit Singh wrote:

> I aim to demonstrate the need for FPGAs as compared to MPUs like (e.g.
> ARM Cortex-M3 based from TI/ST) in doing processing intensive stuff. I
> am looking for some help in this regard. I want to show that a design
> based on MPUs + FPGA will be more faster (feasible?).
> 
> The following is what i have come up with till now,
> 
> Comparing N-Point FFTs Compare designs based on Cordic Huge Calculations
> based on Fixed/Floating points Systems. (ALU Design)
> Are there more novel applications where the FPGA + MPU design achieves
> much more than a single MPU ? It would be great to have some stuff
> pointed at. Happy to read as always :) Thanks.

Well, if there wasn't a need for such things, then there wouldn't be a 
market for FPGAs, now would there?

My work experience with FPGA + CPU designs is that they tend to 
complicate the project management, because you need more good people all 
at the same time.

As an example, given a microcontroller that has a rich enough timer 
feature set, you can do a motor controller board with a good software 
engineer and a good analog circuit designer, with maybe some mutual 
puzzlement around the edges.

Go to do some FPGA-based video processing, and you need a good software 
guy, a good analog guy, and a good FPGA guy.  Depending on how easy it is 
to schedule people in advance at your company, getting one expert from 
each of three disciplines can easily be more than twice as hard as 
getting one expert each from two.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Article: 154903
Subject: Vivado - Pack I/O Registers?
From: padudle@gmail.com
Date: Tue, 12 Feb 2013 05:08:38 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello,

Has anyone found the option in Vivado that controls I/O register packing?

ISE has a single implementation option that forces the default to use the I/O registers on inputs and outputs where possible.  I have not been able to find that option in Vivado.

Thanks for any help.

  Pete

Article: 154904
Subject: Re: Vivado - Pack I/O Registers?
From: peter dudley <padudle@gmail.com>
Date: Tue, 12 Feb 2013 05:46:48 -0800 (PST)
Links: << >>  << T >>  << A >>
I get the following error message.

[Netlist 29-69] Cannot set property 'IOB', because the property does not exist for objects of type 'port'. ["C:/Users/pedro/Xilinx/artix_test/artix_test.srcs/constrs_1/new/top.xdc":7]

Here is my TCL constraints file so far. I just copied the syntax in UG912.

create_clock -period 5.000 -name clk -waveform {0.000 2.500} [get_ports clk]
set_output_delay -clock [get_clocks clk] 4.000 [get_ports {led[0] led[1] led[2] led[3]}]
set_input_delay -clock [get_clocks clk] 3.000 [get_ports enable]
set_property IOB TRUE [get_ports {led[0] led[1] led[2] led[3]}]

Article: 154905
Subject: Re: Chisel as alternative HDL
From: peter dudley <padudle@gmail.com>
Date: Tue, 12 Feb 2013 06:41:55 -0800 (PST)
Links: << >>  << T >>  << A >>
Stick with VHDL.  

You will have to type till your fingers go numb but once something is designed, it stays designed.

  Pete  

Article: 154906
Subject: Re: Idea Hunt, FPGA + ARM Cortex-M3
From: Michael S <already5chosen@yahoo.com>
Date: Tue, 12 Feb 2013 07:14:50 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 9, 4:53=A0pm, Shanjit Singh <shanjitsi...@gmail.com> wrote:
> I aim to demonstrate the need for FPGAs as compared to MPUs like (e.g. AR=
M Cortex-M3 based from TI/ST) in doing processing intensive stuff. I am loo=
king for some help in this regard. I want to show that a design based on MP=
Us + FPGA will be more faster (feasible?).
>
> The following is what i have come up with till now,
>
> Comparing N-Point FFTs
> Compare designs based on Cordic
> Huge Calculations based on Fixed/Floating points Systems. (ALU Design)
> Are there more novel applications where the FPGA + MPU design achieves mu=
ch more than a single MPU ? It would be great to have some stuff pointed at=
. Happy to read as always :) Thanks.

For most of the things you mentioned, comparison of tiny ARM Cortex-M3
against modern low end Xilinx/Altera FPGA is not apple-to-apple
comparison.
FPGAs are bigger, more expensive and esp. if you compare against TI
Stellaris-M3S Series,  produced on much more advanced silicon process.
As an unfortunate consequence of being produced on more advanced
digital process, Xilinx/Altera FPGAs contain no on-chip NOR flash.

So, it's more relevant to compare FPGAs vs products of similar size/
price/silicon generation, e.g. Analog's Blackfin, TI C5000 or C6000
DSPs or ARM Cortex-R4/ARM Cortex-A5 based microcontrollers from your
favorite manufacturer.
In fact even ARM Cortex-A7 cores are much smaller than FPGAs, but
those tend to be integrated in relatively big SOCs.

Article: 154907
Subject: Re: Vivado - Pack I/O Registers?
From: Jan Pech <invalid@void.tld>
Date: Tue, 12 Feb 2013 17:07:39 +0100
Links: << >>  << T >>  << A >>
On Tue, 2013-02-12 at 05:46 -0800, peter dudley wrote:
> I get the following error message.
>=20
> [Netlist 29-69] Cannot set property 'IOB', because the property does
> not exist for objects of type 'port'.
> ["C:/Users/pedro/Xilinx/artix_test/artix_test.srcs/constrs_1/new/top.xdc"=
:7]
>=20
> Here is my TCL constraints file so far. I just copied the syntax in
> UG912.
>=20
> create_clock -period 5.000 -name clk -waveform {0.000 2.500}
> [get_ports clk]
> set_output_delay -clock [get_clocks clk] 4.000 [get_ports {led[0]
> led[1] led[2] led[3]}]
> set_input_delay -clock [get_clocks clk] 3.000 [get_ports enable]
> set_property IOB TRUE [get_ports {led[0] led[1] led[2] led[3]}]


You cannot set IOB on ports. You must do so on the FFs.

Jan


Article: 154908
Subject: Re: Vivado - Pack I/O Registers?
From: muzaffer.kal@gmail.com
Date: Tue, 12 Feb 2013 08:07:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Tuesday, February 12, 2013 5:08:38 AM UTC-8, peter dudley wrote:
> Hello,
> 
> 
> 
> Has anyone found the option in Vivado that controls I/O register packing?
> 
> 
> 
> ISE has a single implementation option that forces the default to use the I/O registers on inputs and outputs where possible.  I have not been able to find that option in Vivado.

IOB is a property on registers so try setting it on the register you want to pack it to an IO location.

Article: 154909
Subject: arm cortex M0 ds and legacy spartan 3E 3A 3ADSP starter kits
From: rp p <rponsard@gmail.com>
Date: Tue, 12 Feb 2013 08:41:01 -0800 (PST)
Links: << >>  << T >>  << A >>
hi folks,
 
I am investigating for edu. purposes arm cortex M0 "design start edition" in legacy spartan3E1600 or 3adsp1800. Labs can't afford new boards this year...
 
I am especially interrested in ddr ram / (arm) ahb-lite wrapping :
mig/mpmc xilinx tools dont have wizard for that bus, it shoud be doable, but tricky... is there something freely available ??
 
 
 
regards

Article: 154910
Subject: Re: Vivado - Pack I/O Registers?
From: peter dudley <padudle@gmail.com>
Date: Tue, 12 Feb 2013 10:18:36 -0800 (PST)
Links: << >>  << T >>  << A >>
So it is back to 1985.  I have to name all my registers or figure out what the synthesis tool calls them and hope they don't change names over time.

In Synopsys there was a trace back feature.  You could trace ports to the nearest register then put the property on that.  It was very indirect and often broke over time, generating very strange error messages.

  Pete

Article: 154911
Subject: Re: Vivado - Pack I/O Registers?
From: gtwrek@sonic.net (Mark Curry)
Date: Tue, 12 Feb 2013 23:19:54 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <43b386bb-a1e6-4ff4-baf2-e24a0c53a857@googlegroups.com>,
peter dudley  <padudle@gmail.com> wrote:
>So it is back to 1985.  I have to name all my registers or figure out
>what the synthesis tool calls them and hope they don't change names
> over time.
>
>In Synopsys there was a trace back feature.  You could trace ports 
>to the nearest register then put the property on that.  It was very 
>indirect and often broke over time, generating very strange error 
>messages.

Can't offer anything other than hoping Xilinx get's back to you with some
sort of general solution.  You're probably a month of so
ahead of me in using Vivado.  Disappointing if we have
all sorts of whiz-bang new flows, but the most basic
things like this just don't work.  

I'd imagine there's gotta be some kind of way to
wildcard it in the new tcl flows.  Just be great if Xilinx
would figure it out and show an example - for a feature
that 99% of it's users will need.

--Mark


Article: 154912
Subject: Aldec Active-HDL - No Default Binding Errors
From: Travis Ayres <trayres@gmail.com>
Date: Tue, 12 Feb 2013 16:30:50 -0800 (PST)
Links: << >>  << T >>  << A >>
I'm getting some errors when I try to compile my design in Aldec's Active-H=
DL.

# Warning: ELAB1_0026: BITADJ128.bde(BITADJ128.vhd) : (79, 0): There is no =
default binding for component "buf". (No entity named "buf" was found).
# Warning: ELAB1_0026: BITADJ128.bde(BITADJ128.vhd) : (157, 0): There is no=
 default binding for component "INV". (No entity named "INV" was found).
# Warning: ELAB1_0026: BITADJ128.bde(BITADJ128.vhd) : (277, 0): There is no=
 default binding for component "GND". (No entity named "GND" was found).

I have added these items to the library multiple times, and in different wa=
ys, but it still gets hosed up. I'm wondering if anyone else has had a simi=
lar issue? I inherited a large design I'm converting from EDIF to VHDL and =
switching from Virtex-4 to Virtex-5, and there seems to be a symbol resolut=
ion problem.

Thanks all!

Article: 154913
Subject: Re: Chisel as alternative HDL
From: Martin Schoeberl <martin@jopdesign.com>
Date: Wed, 13 Feb 2013 06:32:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
peter dudley <padudle@gmail.com> wrote:
> Stick with VHDL.  
> 
> You will have to type till your fingers go numb but once something is
> designed, it stays designed.
> 
>   Pete

Mmh, I'm more and more getting into the chisel thing. I like it and maybe
this gives me (and others, like my students) a productivity boost.

My thoughts about risk: yes, there is a risk with using a new not yet
established language. However, three arguments against being afraid: (1) it
is the design and not the description that counts. If you need to drop a
tool/language, rewriting your design in a new language is not that much
work. (2) it uses Verilog as intermediate language. So the synthesize heavy
lifting is done by the well established tools in a well established
language. (3) it is open source. You can always contribute patches to the
project to fix issues. If they are ignored you can still fork for your
project to survive, although OS project forking is a bad idea.

Cheers,
Martin

Article: 154914
Subject: Re: Vivado - Pack I/O Registers?
From: Jan Pech <invalid@void.tld>
Date: Wed, 13 Feb 2013 08:47:41 +0100
Links: << >>  << T >>  << A >>
On Tue, 2013-02-12 at 10:18 -0800, peter dudley wrote:
> So it is back to 1985.  I have to name all my registers or figure out
> what the synthesis tool calls them and hope they don't change names
> over time.
>=20
> In Synopsys there was a trace back feature.  You could trace ports to
> the nearest register then put the property on that.  It was very
> indirect and often broke over time, generating very strange error
> messages.
>=20
>   Pete


You can track the FFs from your ports using TCL commands in Vivado. I do
not remember the exact syntax but you would use your original
"get_ports" command as a parameter to another TCL command(s) to get your
FFs for the "set_property" command.

I just checked my Vivado training materials and it seems you do not need
to explicitly set IOB to TRUE on all the I/O FFs. The Vivado
implementation does this automatically by default unless you disable it.
You can disable it in the implementation settings using the
"no_timing_driven" option of the "place_design" process.

Jan


Article: 154915
Subject: platform cable usb II and efuses on spartan-6
From: "langwadt@fonz.dk" <langwadt@fonz.dk>
Date: Wed, 13 Feb 2013 11:16:46 -0800 (PST)
Links: << >>  << T >>  << A >>
has anyone managed to do anything with efuses on spartan-6?

I expected to use an old parallel cable since I usually have much need
for jtag, but efuses are only
supported with platform cable usb II, so I got bought one and got it
installed and working on my 64bit
win7 machine only to find out that efuse operations are only supported
on 32bit winxp
(atleast that is what the error mesage says)

no problem I though, I'll just find an old XP machine, but I have now
tried three different 32bit xp machines,
every possible combination of ports/cables/hubs, driver installs/
uninstall/reinstall, ISE versions and every
webcase suggestion I could find and every time I get the same result,
an "unknown usb device"

Is it actually possible to install platform cable use II on winxp?,
and is an obsolete OS on old hardware really
the only option for programming efuses on spartan-6

-Lasse

Article: 154916
Subject: Re: Chisel as alternative HDL
From: jonesandy@comcast.net
Date: Wed, 13 Feb 2013 11:35:31 -0800 (PST)
Links: << >>  << T >>  << A >>
"Mmh, I'm more and more getting into the chisel thing. I like it and maybe =
this gives me (and others, like my students) a productivity boost."

Martin,

I'd rather universities teach students how to get more productivity out of =
the existing, standard, tool-supported HDLs. The status quo, perhaps due to=
 the required simplicity of class projects, is typically an HDL description=
 written at barely above the netlist level anyway. Very little attention is=
 typically paid to SW engineering principles that become critical (and extr=
emely productive) on larger, more complex projects. If these principles and=
 techniques are not taught to HW students, any productivity increases obser=
ved while merely changing languages will be marginal at best. At some point=
, the level of abstraction has to get beyond the current 'This is a registe=
r; these are some gates.' approach to HDL-based design, or it does not matt=
er what language you use.

"My thoughts about risk: yes, there is a risk with using a new not yet esta=
blished language. However, three arguments against being afraid: (1) it is =
the design and not the description that counts. If you need to drop a tool/=
language, rewriting your design in a new language is not that much work."

Does that "not much work" include re-writing your development processes and=
 procedures, coding and review standards, development and verification plan=
s, not to mention test benches? And is this true for most designs, or just =
the typical class project level designs?

"(2) it uses Verilog as intermediate language. So the synthesize heavy lift=
ing is done by the well established tools in a well established language."

So when you get a synthesis error/warning, it refers you to the machine-gen=
erated, intermediate language code, which is cross-referenced to the origin=
al source code how?

MyHDL takes this same approach (it actually produces both VHDL and Verilog =
to support synthesis and other tools). However, the MyHDL source is "elabor=
ated" before the conversion to the supported HDLs, which means that if you =
have a parameterizable source module (that could have been kept parameteriz=
ed in VHDL), you get a separate version of the HDL for every unique paramet=
erization, thus further stretching the already tenuous connection between t=
he source that is written, reviewed and maintained, and the HDL your synthe=
sis tool is warning you about.

"(3) it is open source. You can always contribute patches to the project to=
 fix issues. If they are ignored you can still fork for your project to sur=
vive, although OS project forking is a bad idea. Cheers, Martin"

The tool vendors are unlikely to support an HDL that has no controlled stan=
dard; it's too fluid a target to hit. Until it is controlled and tool-suppo=
rted, its real-world productivity gains are practically zero, if not negati=
ve.

Andy


Article: 154917
Subject: Re: Chisel as alternative HDL
From: Christopher Felton <nospam@nowhere.com>
Date: Wed, 13 Feb 2013 14:28:28 -0600
Links: << >>  << T >>  << A >>
On 2/13/2013 1:35 PM, jonesandy@comcast.net wrote:
> "Mmh, I'm more and more getting into the chisel thing. I like it and maybe this gives me (and others, like my students) a productivity boost."
>
> Martin,
>
> I'd rather universities teach students how to get more productivity out of the existing, standard, tool-supported HDLs. The status quo, perhaps due to the required simplicity of class projects, is typically an HDL description written at barely above the netlist level anyway. Very little attention is typically paid to SW engineering principles that become critical (and extremely productive) on larger, more complex projects. If these principles and techniques are not taught to HW students, any productivity increases observed while merely changing languages will be marginal at best. At some point, the level of abstraction has to get beyond the current 'This is a register; these are some gates.' approach to HDL-based design, or it does not matter what language you use.
>
> "My thoughts about risk: yes, there is a risk with using a new not yet established language. However, three arguments against being afraid: (1) it is the design and not the description that counts. If you need to drop a tool/language, rewriting your design in a new language is not that much work."
>
> Does that "not much work" include re-writing your development processes and procedures, coding and review standards, development and verification plans, not to mention test benches? And is this true for most designs, or just the typical class project level designs?
>
> "(2) it uses Verilog as intermediate language. So the synthesize heavy lifting is done by the well established tools in a well established language."
>
> So when you get a synthesis error/warning, it refers you to the machine-generated, intermediate language code, which is cross-referenced to the original source code how?
>
> MyHDL takes this same approach (it actually produces both VHDL and Verilog to support synthesis and other tools). However, the MyHDL source is "elaborated" before the conversion to the supported HDLs, which means that if you have a parameterizable source module (that could have been kept parameterized in VHDL), you get a separate version of the HDL for every unique parameterization, thus further stretching the already tenuous connection between the source that is written, reviewed and maintained, and the HDL your synthesis tool is warning you about.
>
> "(3) it is open source. You can always contribute patches to the project to fix issues. If they are ignored you can still fork for your project to survive, although OS project forking is a bad idea. Cheers, Martin"
>
> The tool vendors are unlikely to support an HDL that has no controlled standard; it's too fluid a target to hit. Until it is controlled and tool-supported, its real-world productivity gains are practically zero, if not negative.
>
> Andy
>

No way, if they learn how to design and architect complex
digital systems and are able to implement them successfully,
regardless of the tool, I think the students will be prepared
(this depends a lot on the definition of "successfully").

Of course the students will have a learning curve changing HDLs.
But at this point they should have a good idea what the tools
provide and do not provide.  The greater risk is they will be
frustrated not having the power and will quit :)

Regards,
Chris

Article: 154918
Subject: Re: Chisel as alternative HDL
From: Christopher Felton <nospam@nowhere.com>
Date: Wed, 13 Feb 2013 14:33:36 -0600
Links: << >>  << T >>  << A >>
On 2/13/2013 1:35 PM, jonesandy@comcast.net wrote:
<snip>
> MyHDL takes this same approach (it actually produces both VHDL and Verilog to support synthesis and other tools). However, the MyHDL source is "elaborated" before the conversion to the supported HDLs, which means that if you have a parameterizable source module (that could have been kept parameterized in VHDL), you get a separate version of the HDL for every unique parameterization, thus further stretching the already tenuous connection between the source that is written, reviewed and maintained, and the HDL your synthesis tool is warning you about.
>
> "(3) it is open source. You can always contribute patches to the project to fix issues. If they are ignored you can still fork for your project to survive, although OS project forking is a bad idea. Cheers, Martin"
>
> The tool vendors are unlikely to support an HDL that has no controlled standard; it's too fluid a target to hit. Until it is controlled and tool-supported, its real-world productivity gains are practically zero, if not negative.
>
> Andy
>

I have not found this to be an issue, mainly because
I have no synthesis errors after simulating and
cosimulating, the design works as expected.  Yes, if
for some reason you had many synthesis error tracing
back would be more work than tracing to the Verilog/
VHDL source but I think it is minimal compared to
the simulation and verification gains.

Regards,
Chris

Article: 154919
Subject: Re: Chisel as alternative HDL
From: jonesandy@comcast.net
Date: Wed, 13 Feb 2013 13:43:42 -0800 (PST)
Links: << >>  << T >>  << A >>
"I have not found this to be an issue, mainly because I have no synthesis e=
rrors after simulating and cosimulating, the design works as expected. Yes,=
 if for some reason you had many synthesis error tracing back would be more=
 work than tracing to the Verilog/ VHDL source but I think it is minimal co=
mpared to the simulation and verification gains. Regards, Chris"

Chris,

I get very few synthesis "errors" during synthesis, and none by the time I'=
m finished.=20

But I get lots of synthesis "warnings" and "notes" about what is getting op=
timized out, what is being retimed, replicated, etc., even after a design s=
imulates correctly.

Simulating correctly and resulting in reliable hardware are not synonymous.

If you have no synthesis notes/warnings about signals/registers getting opt=
imized away, you are likely designing at an unproductively low level of abs=
traction.=20

When you simulate, are you simulating in the source language, or the interm=
ediate RTL? If at the intermediate RTL level, how are you tracing simulatio=
n errors back to your source? If at the source level, how are you simulatin=
g post-synthesis/P&R (gate level sims) with the same testbench?

Andy




Article: 154920
Subject: Re: Chisel as alternative HDL
From: Christopher Felton <nospam@nowhere.com>
Date: Wed, 13 Feb 2013 16:09:50 -0600
Links: << >>  << T >>  << A >>
On 2/13/2013 3:43 PM, jonesandy@comcast.net wrote:
> "I have not found this to be an issue, mainly because I have no
> synthesis errors after simulating and cosimulating, the design
> works as expected. Yes, if for some reason you had many synthesis
> error tracing back would be more work than tracing to the
> Verilog/ VHDL source but I think it is minimal compared to the
> simulation and verification gains. Regards, Chris"
>
> Chris,
>
> I get very few synthesis "errors" during synthesis, and none by the time I'm finished.
>
> But I get lots of synthesis "warnings" and "notes" about what is getting optimized out, what is being retimed, replicated, etc., even after a design simulates correctly.

Impossible not to get millions of notes and warnings,
the behavior of my final circuits match the behavior
of my descriptions, they work in the field no complaints
thus far.

>
> Simulating correctly and resulting in reliable hardware are not synonymous.

I agree but two ASICs and a dozen successful FPGAs
says what needs to be checked is checked and attention
where attention is required.

>
> If you have no synthesis notes/warnings about signals/registers getting optimized away,

As stated above, with all FPGA tools it is virtually
impossible not to get numerous warnings and errors.
As long as the tools don't change the behavior they
can optimize away.

> "you are likely designing at an unproductively low level of abstraction."

I doubt that!

>
> When you simulate, are you simulating in the source language, or the intermediate RTL? If at the intermediate RTL level, how are you tracing simulation errors back to your source? If at the source level, how are you simulating post-synthesis/P&R (gate level sims) with the same testbench?

I am simulating the source and cosimulating (meaning
using my high-level HDL with the converted and/or
synthesized HDL) and using the high-level verification
environment to verify the converted matches the source.
Optionally, will verify the post P&R (more so with the
ASIC flow less so with FPGA).  I am also able to leverage
the same verification code in the lab, the code that
tested the models also tests the logic in the lab.

>
> Andy
>
>
>


Article: 154921
Subject: Re: Chisel as alternative HDL
From: jonesandy@comcast.net
Date: Thu, 14 Feb 2013 11:14:21 -0800 (PST)
Links: << >>  << T >>  << A >>
Chris,

Do you ignore synthesis notes and warnings, or do you cross-check at least =
some of them?=20

There are precious few efficient ways to confirm "completeness" of the desi=
gn verification effort.

I cross-check my synthesis warnings as a secondary confirmation that someth=
ing is not missed either in the design or in the verification. I can usuall=
y tell from the warning, and knowledge of the design, whether it is a poten=
tial problem or is acceptable/expected. I do not modify the design to elimi=
nate acceptable/expected warnings (that would require designing at too low =
a level of abstraction). It still takes a lot of time, but it has been very=
 effective, not only as a secondary confirmation of verification, but also =
as an indication of where/not to improve performance or utilization to meet=
 requirements.=20

If I used an alternative HDL as source, then I'd have to trace the warnings=
 I could not immediately resolve back through the intermediate code to the =
source. That takes more time, and from what I have seen, would not be offse=
t by any improvmement in productivity provided by the alternative language.=
=20

If I used verilog, I might have a different opinion.=20

However, where other languages, perhaps including these alternative HDLs, m=
ay be more helpful is in the verification of the HDL design, regardless of =
the HDL used (traditional or alternative).

Andy




Article: 154922
Subject: Re: Chisel as alternative HDL
From: Christopher Felton <nospam@nowhere.com>
Date: Thu, 14 Feb 2013 14:17:40 -0600
Links: << >>  << T >>  << A >>
On 2/14/2013 1:14 PM, jonesandy@comcast.net wrote:
> Chris,
>
> Do you ignore synthesis notes and warnings, or do you cross-check at least some of them?

No I don't ignore them, they are reviewed and certain ones
are interrogated if deemed important.  And determining if
they are important is decided by the design engineer,
same as you, they are aware of the design and "no problemo"
referring back to the original source, if needed.

>
> There are precious few efficient ways to confirm "completeness" of the design verification effort.
>
> I cross-check my synthesis warnings as a secondary confirmation that something is not missed either in the design or in the verification. I can usually tell from the warning, and knowledge of the design, whether it is a potential problem or is acceptable/expected. I do not modify the design to eliminate acceptable/expected warnings (that would require designing at too low a level of abstraction). It still takes a lot of time, but it has been very effective, not only as a secondary confirmation of verification, but also as an indication of where/not to improve performance or utilization to meet requirements.
>
> If I used an alternative HDL as source, then I'd have to trace the warnings I could not immediately resolve back through the intermediate code to the source. That takes more time, and from what I have seen, would not be offset by any improvmement in productivity provided by the alternative language.
>
> If I used verilog, I might have a different opinion.
>
> However, where other languages, perhaps including these alternative HDLs, may be more helpful is in the verification of the HDL design, regardless of the HDL used (traditional or alternative).
>
> Andy
>

In this case the alternative HDL used is MyHDL, and MyHDL
-in my experience- does not mangle the source enough to
prohibit tracing back.  As you indicated, it does have an
"elaboration" phase but this has not been an issue (tracing
back the generated VHDL or Verilog).

I agree, the alternative HDL (because they are typically
based on as general purpose high-level language) are ideal
for modeling and verification.  The V*s will always lag the
other languages for general features.

Regards,
Chris



Article: 154923
Subject: OSERDES as delay regulator e.g. Artix 7
From: awelker@students.uni-mainz.de
Date: Fri, 15 Feb 2013 02:18:40 -0800 (PST)
Links: << >>  << T >>  << A >>
Dear all,
as some of you know that the Artix 7 has no ODELAY so I can't handle my delays for the output. But there is a OSERDES as well with MMCM or the PLL to manage output pins with different phases e.g.

My question is, how can I implement OSERDES fragments so that I can say please create a delay for 3ns before you send the signals.(I know there is a IPcatalog Manager, but I don't know how I can use it to creat a delay with it) 

Hope you can help me.

Thank you very much.

Article: 154924
Subject: ModelSim version numbers
From: "RCIngham" <2161@embeddedrelated>
Date: Fri, 15 Feb 2013 11:59:10 -0600
Links: << >>  << T >>  << A >>
Does anyone know why ModelSim version numbers skipped from 6.6 to 10,
missing out 7, 8,and 9?

Thanks in anticipation.


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



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
2017JanFebMarApr2017

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