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
Anyone know if there are any gotcha's with working with multiple Quartus (II v. 4) projects on the same computer? I'd like to work several approaches simultaneously, but not if there are side effects - subtle or otherwise. Thanks, KenArticle: 69326
All -
Thanks for your comments on my problem.
I'm also a bit worried about using false paths, but I
think this one *might* be safe:
NET "upatgen/*_inst_cy_*" TPTHRU = "thru_carry";
TIMESPEC "TS_seq_rd_addr" =
FROM RAMS(upatgen/seq_rd_data<*>)
THRU "thru_carry"
TO FFS (upatgen/rd_addr<*>) 10ns;
I'm a bit worried that this could be toooo agressive, is there
a way to to restrict this specifically to the COUT/CIN pins?
John P
"Symon" <symon_brewer@hotmail.com> wrote in message news:<c7bac9$21dk9$1@ID-212844.news.uni-berlin.de>...
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:4099217F.9E954847@andraka.com...
> > My preference is to try
> > to make it pass without declaring false paths because of the danger of
> > inadvertently marking a valid path as false.
> >
> Indeed, be careful with declaring false paths
> I noticed the clock skew was quite high(!) at 113ps. Does the carry chain
> straddle different bits of the clock tree? You could try locking it down to
> reduce the skew. You only need 8ps! Or, you could tell the timing analyser
> your worst case temperature and power supply voltage to get back the 8ps.
> good luck, Syms.
Article: 69327Matthew E Rosenthal wrote: > Unfortunately that can not be implemented. I was hoping for something > specific to bram clock-> Q delay. The BlockRAM CLK -> Q can only be improved by going to a faster speed grade. If that is out of the question and adding latency is not an option then you have two choices, either look elsewhere to reduce the path delays or not use the BlockRAM. You mention that you do not need the RAM very deep but do need it very wide. Have you considered using LUT-based RAM (RAM16X1S)? You can configure LUT-based RAM fairly easily in 16, 32 and 64 bit depths and will see a better CLK -> Q than in the BlockRAMs and on top of that, likely see better placement for wider buses since they are not all tied together like they are in a BlockRAM. Also, LUT-RAMs have asynchronous reads so if you want to keep that clock cycle of latency for your reads, you can either add a register to the output of the RAM in the same slice and get that latency back and still get a good CLK --> Q or else you can push that register deeper into you critical path and perhaps get a better balance of registers in that path and thus get much better timing. You can configure the LUT-RAMs to depths deeper than 64-bits but you start to consume a lot of LUT resources and the trade-off is not as great. My suggestion is if you can get by with 64-bits or less ore bit, might as well go to LUT-RAM. If you need deeper RAMs, stay in the BlockRAM and look at reducing routing delays (you can try adding placement constraints, replicating registers/logic, higher effort levels in Map/Par, etc.) or logic levels for those critical paths (try harder synthesis constraints/options, re-coding that section of the design, etc.). Good Luck, -- Brian > > > Matt > On Wed, 5 May 2004, Peter Alfke wrote: > > >>Pipelining is the most obvious and most popular way to reduce long delays. >>When it can be used, it is great... >>Peter Alfke >> >> >>>From: Matthew E Rosenthal <mer2@andrew.cmu.edu> >>>Organization: Carnegie Mellon, Pittsburgh, PA >>>Newsgroups: comp.arch.fpga >>>Date: Wed, 5 May 2004 18:50:30 -0400 (EDT) >>>Subject: V2p block ram clock -> Q delay help >>> >>>Hi all, >>>I have a long combinational path in my fpga design and I am looking for >>>ways to reduce the path. one of the biggest contributors is the clock to >>>Q delay from memory on some of the inputs to the path. The >>>memory(blockram) is currently very wide and not deep. >>>Is there a way to optimize the size or any other paramaters to decrease >>>the clock to Q time? >>> >>>Thanks >>> >>>Matt >> >>Article: 69328
Hey Javid, Using Synplify? Look up syn_direct_enable in the manual. Cheers, Syms.Article: 69329
Peter Sommerfeld wrote:
> Thanks for the reply. I must be on the right track, because it looks
> like I have been doing what you suggested in
> http://groups.google.com/groups?q=gaggle.DSPaddr. However, the InitBus
> call causes compile errors in my design.
You have stumbled onto the procedure scope problem.
Re-read that thread and see the lines I added
to my example architecture below.
-- Mike Treseler
------------------------------------------------------------
architecture synth of signal_structure is
-- note, I changed your type to data in and out signals
type DSPIF_type is
record
DSPaddr : std_logic_vector(23 downto 0);
DSPdata_in : std_logic_vector(31 downto 0);
DSPdata_out : std_logic_vector(31 downto 0);
nDHOLD : std_logic;
nDHOLDA : std_logic;
nDPAGE : std_logic_vector(3 downto 0);
nDSTRB : std_logic;
nDBE : std_logic_vector(3 downto 0);
nDOE : std_logic;
nDWE : std_logic;
nDRDY : std_logic;
end record;
signal gaggle : DSPIF_type;
signal output_enabled : boolean;
-------------------------------------------------------------------------------
-- Added proc example in scope
procedure InitBus( signal gaggle: inout DSPIF_type )
is begin end InitBus;
-------------------------------------------------------------------------------
begin
-- wire up signal structure to pins
gaggle.DSPaddr <= DSPaddr;
gaggle.DSPdata_in <= DSPdata;
-- . . . (rest of INs go here)
-- then OUTs:
nDHOLD <= gaggle.nDRDY;
nDRDY <= gaggle.nDRDY;
DSPdata <= gaggle.DSPdata_out when output_enabled
else (DSPdata'range => 'Z');
-- processes using the gaggle signals go here
end architecture synth;
-- Mike Treseler
Article: 69330"Student" <student@nowhere.com> wrote in message news:409866a1@news.starhub.net.sg... > Hi, there: > > I am compiling a design which takes up 80% of the XC2V6000...After I put in > the > bus macros and run implementation, I found that there are a large number of > wire > crossings...For example, some VCC_FAKE_LEFT can route as long as three > slices > into the Right...vice versa...These wires just run into a switch boxes on > the opposite > side then flip back, but not connected to any slices I think...The same > phenomenon > never happened in my previous design which only uses 30% of the FPGA... > > Is this acceptable for a partially reconfigurable design? > > Best Regards, > Kelvin > Just as with sausages, you don't want to delve too deeply into the construction of an implemented FPGA. The router uses an iterative process which might not yield the perfect solution, but usually one that works. Even if it's not perfect, there's not much you can do about it. Just try some hand routing and you will be happy to let the router work on its own. -KevinArticle: 69331
Sean Durkin wrote: > ssaleem wrote: > >> Can someone tell me about the steps to partially reconfigure Vertex-II >> FPGA's with some simple example? > > I recommend Application Note 290: > > http://www.xilinx.com/bvdocs/appnotes/xapp290.pdf > > There are no really simple examples for partial reconfiguration, since > it just is not that simple... The simplest way I know to actually demonstrate partial reconfig is to hand edit a trivial design in fpga_editor, eg route vcc to an IOB, generate the NCD file, run bitgen to get a .bit file, then edit the NCD again but route that same IOB to ground, save the new NCD, re-run bitgen with the -r option, to create a partial bitstream relative to the first one. Then, configure with the first bitstream, the IOB goes high (choose one that's connected to an LED on the board), then download the partial bitstream, the LED should turn off. Congratulations, you have entered the race for the most complicated blinkenlight application, just like the rest of us! So, it's partial reconfig, but entirely useless. Next, start exploring the tools to generate partial bitstreams in a modular fashion. Feel free to subscribe to the partial-reconfig mailing list, and ask questions/discuss there. It's quiet, but still interesting: email majorodomo@itee.uq.edu.au, with *body text* "subscribe partial-reconfig" (no quotes) Regards, JohnArticle: 69332
This is an artifact of Xilinx's place and route must finish faster philosophy.
It used to be that if you got a good placement, the route would be near optimal
for that placement. As devices got bigger, the route time increased too much
for auto-placed designs, so now the router only works as hard as it needs to to
meet timing. The result is you get many routes that do not take the shortest
path, and worse, many nets become the critical path. In a densely placed
design, the result is the routing gets congested and the tools may not find a
routing solution that meets timing at all. Apparently, not many of Xilinx's
big customers are running the FPGAs at the top of the performance envelope,
because if they were I am sure this would be a much highr priority issue.
As for partial reconfiguration, this behavior is a train-wreck. In order to be
successful, you need to keep the routing within the slices you are
reconfiguring. The current tools have no apparent way of putting fences around
the logic to keep a route in or out of an area.
Student wrote:
> Hi, there:
>
> I am compiling a design which takes up 80% of the XC2V6000...After I put in
> the
> bus macros and run implementation, I found that there are a large number of
> wire
> crossings...For example, some VCC_FAKE_LEFT can route as long as three
> slices
> into the Right...vice versa...These wires just run into a switch boxes on
> the opposite
> side then flip back, but not connected to any slices I think...The same
> phenomenon
> never happened in my previous design which only uses 30% of the FPGA...
>
> Is this acceptable for a partially reconfigurable design?
>
> Best Regards,
> Kelvin
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 69333
Hi Mike,
Yes I found my problem, and it was unfortunately in a part of my
record that I didn't post. In my record, I had a field that was of the
physical type time which I was using inside my procedures for certain
delays. ie:
type rec is record
...
clock_period : time;
...
end record;
So while I was assuming a signal-driving issue to be the problem, it
was this field (which is still bizarre, because I set this field only
once and never write it again, therefore, I would have thought, it
could not be a problem). Anyways, I replaced this field with a clock
signal which makes more sense now anyways and everything works great,
and thanks to yours and Jim's replies, I understand what's going on
much better too. I had better post the whole thing the next time I
have a problem like this.
-- Pete
> Peter Sommerfeld wrote:
>
> > Thanks for the reply. I must be on the right track, because it looks
> > like I have been doing what you suggested in
> > http://groups.google.com/groups?q=gaggle.DSPaddr. However, the InitBus
> > call causes compile errors in my design.
>
> You have stumbled onto the procedure scope problem.
> Re-read that thread and see the lines I added
> to my example architecture below.
>
> -- Mike Treseler
>
>
> ------------------------------------------------------------
> architecture synth of signal_structure is
> -- note, I changed your type to data in and out signals
>
> type DSPIF_type is
> record
> DSPaddr : std_logic_vector(23 downto 0);
> DSPdata_in : std_logic_vector(31 downto 0);
> DSPdata_out : std_logic_vector(31 downto 0);
> nDHOLD : std_logic;
> nDHOLDA : std_logic;
> nDPAGE : std_logic_vector(3 downto 0);
> nDSTRB : std_logic;
> nDBE : std_logic_vector(3 downto 0);
> nDOE : std_logic;
> nDWE : std_logic;
> nDRDY : std_logic;
> end record;
>
> signal gaggle : DSPIF_type;
> signal output_enabled : boolean;
> -------------------------------------------------------------------------------
> -- Added proc example in scope
> procedure InitBus( signal gaggle: inout DSPIF_type )
> is begin end InitBus;
> -------------------------------------------------------------------------------
> begin
> -- wire up signal structure to pins
> gaggle.DSPaddr <= DSPaddr;
> gaggle.DSPdata_in <= DSPdata;
> -- . . . (rest of INs go here)
> -- then OUTs:
> nDHOLD <= gaggle.nDRDY;
> nDRDY <= gaggle.nDRDY;
> DSPdata <= gaggle.DSPdata_out when output_enabled
> else (DSPdata'range => 'Z');
>
> -- processes using the gaggle signals go here
>
> end architecture synth;
>
>
> -- Mike Treseler
Article: 69334I tried to define a guard area on the 8 slices where I placed the Bus Macros, basically I defined some additional area_groups to contain the placement of submodules, leaving the 8 slices gap not filled by much logic... The wire crossing got better, but never gone... What other tricks may I try? Best Regards, Kelvin "Ray Andraka" <ray@andraka.com> wrote in message news:409AE2E6.F229545C@andraka.com... > This is an artifact of Xilinx's place and route must finish faster philosophy. > It used to be that if you got a good placement, the route would be near optimal > for that placement. As devices got bigger, the route time increased too much > for auto-placed designs, so now the router only works as hard as it needs to to > meet timing. The result is you get many routes that do not take the shortest > path, and worse, many nets become the critical path. In a densely placed > design, the result is the routing gets congested and the tools may not find a > routing solution that meets timing at all. Apparently, not many of Xilinx's > big customers are running the FPGAs at the top of the performance envelope, > because if they were I am sure this would be a much highr priority issue. > > As for partial reconfiguration, this behavior is a train-wreck. In order to be > successful, you need to keep the routing within the slices you are > reconfiguring. The current tools have no apparent way of putting fences around > the logic to keep a route in or out of an area. > > Student wrote: > > > Hi, there: > > > > I am compiling a design which takes up 80% of the XC2V6000...After I put in > > the > > bus macros and run implementation, I found that there are a large number of > > wire > > crossings...For example, some VCC_FAKE_LEFT can route as long as three > > slices > > into the Right...vice versa...These wires just run into a switch boxes on > > the opposite > > side then flip back, but not connected to any slices I think...The same > > phenomenon > > never happened in my previous design which only uses 30% of the FPGA... > > > > Is this acceptable for a partially reconfigurable design? > > > > Best Regards, > > Kelvin > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 69335
Peter, You can convert time to std_logic_vector by converting it to integer first: i_int <= NOW / 1 ns ; -- now an integer value with ns units time_slv <= std_logic_vector(to_unsigned(i_int, time_slv'length)) ; Cheers, Jim Sommerfeld wrote: > Hi Mike, > > Yes I found my problem, and it was unfortunately in a part of my > record that I didn't post. In my record, I had a field that was of the > physical type time which I was using inside my procedures for certain > delays. ie: > > type rec is record > ... > clock_period : time; > ... > end record; > > So while I was assuming a signal-driving issue to be the problem, it > was this field (which is still bizarre, because I set this field only > once and never write it again, therefore, I would have thought, it > could not be a problem). Anyways, I replaced this field with a clock > signal which makes more sense now anyways and everything works great, > and thanks to yours and Jim's replies, I understand what's going on > much better too. I had better post the whole thing the next time I > have a problem like this. > > -- Pete > > >>Peter Sommerfeld wrote: >> >> >>>Thanks for the reply. I must be on the right track, because it looks >>>like I have been doing what you suggested in >>>http://groups.google.com/groups?q=gaggle.DSPaddr. However, the InitBus >>>call causes compile errors in my design. >> >>You have stumbled onto the procedure scope problem. >>Re-read that thread and see the lines I added >>to my example architecture below. >> >> -- Mike Treseler >> >> >>------------------------------------------------------------ >>architecture synth of signal_structure is >> -- note, I changed your type to data in and out signals >> >> type DSPIF_type is >> record >> DSPaddr : std_logic_vector(23 downto 0); >> DSPdata_in : std_logic_vector(31 downto 0); >> DSPdata_out : std_logic_vector(31 downto 0); >> nDHOLD : std_logic; >> nDHOLDA : std_logic; >> nDPAGE : std_logic_vector(3 downto 0); >> nDSTRB : std_logic; >> nDBE : std_logic_vector(3 downto 0); >> nDOE : std_logic; >> nDWE : std_logic; >> nDRDY : std_logic; >> end record; >> >> signal gaggle : DSPIF_type; >> signal output_enabled : boolean; >>------------------------------------------------------------------------------- >> -- Added proc example in scope >> procedure InitBus( signal gaggle: inout DSPIF_type ) >> is begin end InitBus; >>------------------------------------------------------------------------------- >>begin >> -- wire up signal structure to pins >> gaggle.DSPaddr <= DSPaddr; >> gaggle.DSPdata_in <= DSPdata; >>-- . . . (rest of INs go here) >>-- then OUTs: >> nDHOLD <= gaggle.nDRDY; >> nDRDY <= gaggle.nDRDY; >> DSPdata <= gaggle.DSPdata_out when output_enabled >> else (DSPdata'range => 'Z'); >> >>-- processes using the gaggle signals go here >> >>end architecture synth; >> >> >> -- Mike Treseler -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Article: 69336
Howdy all, I'm looking to get an FPGA development board sometime soon. When I was in college, I played with what was probably the Xess XSB-300E (fun stuff: we made a PCMCIA interface and plugged it into an iPaq... but that's another story). That's WAY outside of my price range (< $200US), but the XSA-50 doesn't look too bad. Any comments on that one? Also, I found this (www.nuhorizons.com/products/xilinx/spartan3/development-board.html), which looks considerably better to me, especially since my main prospective project would benefit from a large amount of fast RAM. Any advice? Is there anything else in the sub-$200 I should look at? Also, what's the status of open source tools? (I like to tinker on the software end of things, too, and I have a bad case of PowerBook envy, and I haven't seen any software available other than x86 and big-iron UNIX). Can they go from VHDL/Verilog all the way to downloading the file to the chip? I see that compilation (Icarus verilog) and downloading (found it in this group's FAQ) work, but what about place and route? Icarus' docs say it's a no-go for this; is there anything else, or must I use the Xilinx tools? (I guess I have a Xilinx bias -- it's all I've used, and I don't see much else for cheap development boards.) Thanks for the help! - Joel HardyArticle: 69337
Peter,
As a PS to my other post, to date I have found
that if I want to work with a single record,
I have been limited to std_logic family.
I have tried tinkering with integers and resolution
functions, but have had problems with resolving a value
to drive when the record field is not to be driven.
It seems that the resolution function is called at the
block level and there currently no way I could find to
work around this.
This is a topic we are kicking around in the VHDL-200X
effort. I had wished for it to be part of the fast track
effort and I made a proposal, but it is not clear even to
me that the proposal is the best long term solution, so I
don't want to push it. My preference is to see what comes
up when we give more time and consideration to the problem.
For more on the vhdl-200x effort, see:
http://www.eda.org/vhdl-200x
IEEE standards are open to public participation.
Best Regards,
Jim
> Hi Mike,
>
> Yes I found my problem, and it was unfortunately in a part of my
> record that I didn't post. In my record, I had a field that was of the
> physical type time which I was using inside my procedures for certain
> delays. ie:
>
> type rec is record
> ...
> clock_period : time;
> ...
> end record;
>
> So while I was assuming a signal-driving issue to be the problem, it
> was this field (which is still bizarre, because I set this field only
> once and never write it again, therefore, I would have thought, it
> could not be a problem). Anyways, I replaced this field with a clock
> signal which makes more sense now anyways and everything works great,
> and thanks to yours and Jim's replies, I understand what's going on
> much better too. I had better post the whole thing the next time I
> have a problem like this.
>
> -- Pete
>
>
>>Peter Sommerfeld wrote:
>>
>>
>>>Thanks for the reply. I must be on the right track, because it looks
>>>like I have been doing what you suggested in
>>>http://groups.google.com/groups?q=gaggle.DSPaddr. However, the InitBus
>>>call causes compile errors in my design.
>>
>>You have stumbled onto the procedure scope problem.
>>Re-read that thread and see the lines I added
>>to my example architecture below.
>>
>> -- Mike Treseler
>>
>>
>>------------------------------------------------------------
>>architecture synth of signal_structure is
>> -- note, I changed your type to data in and out signals
>>
>> type DSPIF_type is
>> record
>> DSPaddr : std_logic_vector(23 downto 0);
>> DSPdata_in : std_logic_vector(31 downto 0);
>> DSPdata_out : std_logic_vector(31 downto 0);
>> nDHOLD : std_logic;
>> nDHOLDA : std_logic;
>> nDPAGE : std_logic_vector(3 downto 0);
>> nDSTRB : std_logic;
>> nDBE : std_logic_vector(3 downto 0);
>> nDOE : std_logic;
>> nDWE : std_logic;
>> nDRDY : std_logic;
>> end record;
>>
>> signal gaggle : DSPIF_type;
>> signal output_enabled : boolean;
>>-------------------------------------------------------------------------------
>> -- Added proc example in scope
>> procedure InitBus( signal gaggle: inout DSPIF_type )
>> is begin end InitBus;
>>-------------------------------------------------------------------------------
>>begin
>> -- wire up signal structure to pins
>> gaggle.DSPaddr <= DSPaddr;
>> gaggle.DSPdata_in <= DSPdata;
>>-- . . . (rest of INs go here)
>>-- then OUTs:
>> nDHOLD <= gaggle.nDRDY;
>> nDRDY <= gaggle.nDRDY;
>> DSPdata <= gaggle.DSPdata_out when output_enabled
>> else (DSPdata'range => 'Z');
>>
>>-- processes using the gaggle signals go here
>>
>>end architecture synth;
>>
>>
>> -- Mike Treseler
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Article: 69338"Kenneth Land" <kland1@neuralog1.com1> writes: > Anyone know if there are any gotcha's with working with multiple Quartus (II > v. 4) projects on the same computer? > > I'd like to work several approaches simultaneously, but not if there are > side effects - subtle or otherwise. I naver had any problem with multiple projects and Quartus under Linux and Solaris at least. However, I'm using mostly scripts in my flow, and minimal amount of GUI. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 69339
> Also, what's the status of open source tools? (I like to tinker on > the software end of things, too, and I have a bad case of PowerBook > envy, and I haven't seen any software available other than x86 and > big-iron UNIX). Can they go from VHDL/Verilog all the way to > downloading the file to the chip? I see that compilation (Icarus > verilog) and downloading (found it in this group's FAQ) work, but what > about place and route? Icarus' docs say it's a no-go for this; is > there anything else, or must I use the Xilinx tools? (I guess I have > a Xilinx bias -- it's all I've used, and I don't see much else for > cheap development boards.) Why bother with Open Source stuff when various incarnations of commerical tools are free to use? Check out for the Xilinx WebPack: http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack Cheers, JonBArticle: 69340
deeng_temp@yahoo.com (Joel Hardy) wrote in message news:<91268129.0405062217.35c0b0cd@posting.google.com>... > Howdy all, > > I'm looking to get an FPGA development boarXess XSB-300E (fun > stuff: we made a PCMCIA interface and plugged it into an iPaq... but > that's another story). That's WAY outside of my price range (< > $200US), but the XSA-50 doesn't lookd sotoo bad. Any comments on that > one? Also, I found thisprobably the anything else in the sub-$200 I should look at? > > Also, what's the status of open source tools? (I like to tinker on > the software end of things, too, and I have a bad case of PowerBook > envy, and I haven't seen any software available o > (www.nuhorizons.com/products/xilinx/spartan3/development-board.html), > which looks considerably better to me, especially since my main > prospective project would benefit from a large amount of fast RAM. > Any advice? Is there metime soon. When I > was in college, I played with what was ther than x86 and > big-iron UNIX). Can they go from VHDL/Verilog all the way to > downloading the file to the chip? I see that compilation (Icarus > verilog) and downloading (found it in this group's FAQ) work, but what > about place and route? Icarus' docs say it's a no-go for this; is > there anything else, or must I use the Xilinx tools? (I guess I have > a Xilinx bias -- it's all I've used, and I don't see much else for > cheap development boards.) > > Thanks for the help! > - Joel Hardy Apart from entry level HDL simulation, I wouldn't expect too much from open source for anything really difficult. The structure of FPGAs is generally too complicated & proprietary for opensource. It was different when everyone was doing ASIC & polygon design, then anyone could write code that would work with any vendor. You can run the free WebPack under VPC for Mac and take the speed hit, interested to see a comparison of that v near equiv x86 running native. I'd bet its 10x slower. you can google geda, open source eda tools, there are quite a few out there but mostly not much updated. Also hang out in the verilog/vhdl NGs. regards johnjakson_usa_comArticle: 69341
"Kenneth Land" <kland1@neuralog1.com1> wrote in message
news:109kls5eqph5vcc@news.supernews.com...
> Anyone know if there are any gotcha's with working with multiple Quartus
(II
> v. 4) projects on the same computer?
>
Hi Ken,
Based on the Quartus architecture you should not:
1. Open the SAME project in multiple Quartus instances, i.e. each Quartus
instance should work on a different project.
2. Do not open a project from the UI and then run the command line compiler
executables from a DOS prompt/command shell (quartus_map, quartus_fit,
quartus_tan, quartus_asm ...) on the same project. Use the UI or the command
line exclusively at any point in your design flow. You can switch between
the two as needed.
3. Don't open and/or close more than one instance of Quartus at exactly the
SAME time. Basically, if one instance of Quartus is trying to close down, it
is in the process of writing stuff to the registry. Then during that time,
another instance of Quartus just starting up may be trying to read that data
whcih may not be correct. Therefore if you initiate a closing of a Quartus
instance let it close fully before you open another one.
Apart from these you are ready to go. Hope this helps.
- Subroto Datta
Altera Corp.
Article: 69342Hi Jim, Yes I would love to participate in the VHDL-200X effort. It's nice to see it's open to the non-members. Is there a target release date for VHDL-200X? This problem of the fields of a record appearing to be resolved as a group, and not individually, is particularly vexing to me. Hopefully I won't have to deal with it in the next VHDL version. -- Pete > Peter, > As a PS to my other post, to date I have found > that if I want to work with a single record, > I have been limited to std_logic family. > > I have tried tinkering with integers and resolution > functions, but have had problems with resolving a value > to drive when the record field is not to be driven. > It seems that the resolution function is called at the > block level and there currently no way I could find to > work around this. > > This is a topic we are kicking around in the VHDL-200X > effort. I had wished for it to be part of the fast track > effort and I made a proposal, but it is not clear even to > me that the proposal is the best long term solution, so I > don't want to push it. My preference is to see what comes > up when we give more time and consideration to the problem. > > For more on the vhdl-200x effort, see: > http://www.eda.org/vhdl-200x > > IEEE standards are open to public participation. > > Best Regards, > Jim > > > > Hi Mike, > > > > Yes I found my problem, and it was unfortunately in a part of my > > record that I didn't post. In my record, I had a field that was of the > > physical type time which I was using inside my procedures for certain > > delays. ie: > > > > type rec is record > > ... > > clock_period : time; > > ... > > end record; > > > > So while I was assuming a signal-driving issue to be the problem, it > > was this field (which is still bizarre, because I set this field only > > once and never write it again, therefore, I would have thought, it > > could not be a problem). Anyways, I replaced this field with a clock > > signal which makes more sense now anyways and everything works great, > > and thanks to yours and Jim's replies, I understand what's going on > > much better too. I had better post the whole thing the next time I > > have a problem like this. > > > > -- Pete > > > > > >>Peter Sommerfeld wrote: > >> > >> > >>>Thanks for the reply. I must be on the right track, because it looks > >>>like I have been doing what you suggested in > >>>http://groups.google.com/groups?q=gaggle.DSPaddr. However, the InitBus > >>>call causes compile errors in my design. > >> > >>You have stumbled onto the procedure scope problem. > >>Re-read that thread and see the lines I added > >>to my example architecture below. > >> > >> -- Mike Treseler > >> > >> > >>------------------------------------------------------------ > >>architecture synth of signal_structure is > >> -- note, I changed your type to data in and out signals > >> > >> type DSPIF_type is > >> record > >> DSPaddr : std_logic_vector(23 downto 0); > >> DSPdata_in : std_logic_vector(31 downto 0); > >> DSPdata_out : std_logic_vector(31 downto 0); > >> nDHOLD : std_logic; > >> nDHOLDA : std_logic; > >> nDPAGE : std_logic_vector(3 downto 0); > >> nDSTRB : std_logic; > >> nDBE : std_logic_vector(3 downto 0); > >> nDOE : std_logic; > >> nDWE : std_logic; > >> nDRDY : std_logic; > >> end record; > >> > >> signal gaggle : DSPIF_type; > >> signal output_enabled : boolean; > >>------------------------------------------------------------------------------- > >> -- Added proc example in scope > >> procedure InitBus( signal gaggle: inout DSPIF_type ) > >> is begin end InitBus; > >>------------------------------------------------------------------------------- > >>begin > >> -- wire up signal structure to pins > >> gaggle.DSPaddr <= DSPaddr; > >> gaggle.DSPdata_in <= DSPdata; > >>-- . . . (rest of INs go here) > >>-- then OUTs: > >> nDHOLD <= gaggle.nDRDY; > >> nDRDY <= gaggle.nDRDY; > >> DSPdata <= gaggle.DSPdata_out when output_enabled > >> else (DSPdata'range => 'Z'); > >> > >>-- processes using the gaggle signals go here > >> > >>end architecture synth; > >> > >> > >> -- Mike Treseler > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jim Lewis > Director of Training mailto:Jim@SynthWorks.com > SynthWorks Design Inc. http://www.SynthWorks.com > 1-503-590-4787 > > Expert VHDL Training for Hardware Design and Verification > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Article: 69343
Hello I've got following problem: I need 27MHz and 54MHz clocks, input freq. is 20MHz. Till today I used DCM FS 27/20 next to DLL and DLL*2. Theoreticly it should works OK, but doesn't. From time to time after reboot or after clok stop, it works strange and completly bad. Today I've read about jitter on output of DCM's CLKFX, I check on "Virtex-II CLKFX Jitter Calculator" that in this conditions I have over 2 ns jitter on CLKFX output, which is to big for DLL input CLKIN. So I try to do this way: DCM FS 27/5 - I have 108MHz next to DLL/4 and DLL*2 The jitter on CLKFX should be below 1ns and now it must work but doesn't. What should I check else? Please help me, I lose my hair :> Best regards Jerzy GburArticle: 69344
Hi,
in order to verify the functionality of XILINX DCM, I have generated a
dcm.vhd file with the ISE 6.2 architecture wizard. The dcm module is
embedded into a simple top-level file that only connects the testbench
signals (in-clock and reset (=0) to the DCM-module. The DCM reset
signal is always set to '0'.
Unfortunately, during the simulation with Modelsim, I do not obtain
the 4x clock signal of the input clock at the output (CLKFX_OUT) but
always '0'. CLK0_OUT is always '0', but CLKIN_IBUFG_OUT follows the
input clock signal.
What can be the reason for this behavior ?
Regards
Juergen
------------------------------------------------------------------------------
Below: the dcm file generated by architecture wizard
-- Module dyna_dcm
-- Generated by Xilinx Architecture Wizard
-- VHDL
-- Written for synthesis tool: XST
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
-- synopsys translate_off
Library UNISIM;
use UNISIM.Vcomponents.all;
-- synopsys translate_on
entity dyna_dcm is
port (
RST_IN : in std_logic;
CLKIN_IN : in std_logic;
LOCKED_OUT : out std_logic;
CLKFX_OUT : out std_logic;
CLKIN_IBUFG_OUT : out std_logic;
CLK0_OUT : out std_logic);
end dyna_dcm;
architecture STRUCT of dyna_dcm is
signal CLKIN_IBUFG : std_logic;
signal CLKFB_IN : std_logic;
signal CLK0_BUF : std_logic;
signal CLKFX_BUF : std_logic;
signal GND : std_logic;
-- Period Jitter (unit interval) = 0.17 UI
-- Period Jitter (Peak-to-Peak) = 0.63 ns
component DCM
generic(
CLKDV_DIVIDE : real := 2.0;
CLKFX_DIVIDE : integer := 1;
CLKFX_MULTIPLY : integer := 4;
CLKIN_DIVIDE_BY_2 : boolean := false;
CLKIN_PERIOD : real := 0.0;
CLKOUT_PHASE_SHIFT : string := "NONE";
CLK_FEEDBACK : string := "1X";
DESKEW_ADJUST : string := "SYSTEM_SYNCHRONOUS";
DFS_FREQUENCY_MODE : string := "LOW";
DLL_FREQUENCY_MODE : string := "LOW";
DSS_MODE : string := "NONE";
DUTY_CYCLE_CORRECTION : boolean := true;
FACTORY_JF : bit_vector := X"C080";
MAXPERCLKIN : time := 1000000 ps;
MAXPERPSCLK : time := 100000000 ps;
PHASE_SHIFT : integer := 0;
SIM_CLKIN_CYCLE_JITTER : time := 300 ps;
SIM_CLKIN_PERIOD_JITTER : time := 1000 ps;
STARTUP_WAIT : boolean := false
);
port (
CLKIN : in std_logic;
CLKFB : in std_logic;
RST : in std_logic;
PSEN : in std_logic;
PSINCDEC : in std_logic;
PSCLK : in std_logic;
DSSEN : in std_logic;
CLK0 : out std_logic;
CLK90 : out std_logic;
CLK180 : out std_logic;
CLK270 : out std_logic;
CLKDV : out std_logic;
CLK2X : out std_logic;
CLK2X180 : out std_logic;
CLKFX : out std_logic;
CLKFX180 : out std_logic;
STATUS : out std_logic_vector (7 downto 0);
LOCKED : out std_logic;
PSDONE : out std_logic
);
end component;
component IBUFG
port (
I : in std_logic;
O : out std_logic
);
end component;
component BUFG
port (
I : in std_logic;
O : out std_logic
);
end component;
begin
DCM_INST : DCM
Generic map (
CLK_FEEDBACK => "1X",
CLKDV_DIVIDE => 2.0,
CLKFX_DIVIDE => 1,
CLKFX_MULTIPLY => 4,
CLKIN_DIVIDE_BY_2 => FALSE,
CLKIN_PERIOD => 15.1515,
CLKOUT_PHASE_SHIFT => "NONE",
DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS",
DFS_FREQUENCY_MODE => "HIGH",
DLL_FREQUENCY_MODE => "LOW",
DUTY_CYCLE_CORRECTION => TRUE,
PHASE_SHIFT => 0,
STARTUP_WAIT => FALSE)
port map (
CLKIN => CLKIN_IBUFG,
CLKFB => CLKFB_IN,
RST => RST_IN,
PSEN => GND,
PSINCDEC => GND,
PSCLK => GND,
DSSEN => GND,
CLK0 => CLK0_BUF,
CLKFX => CLKFX_BUF,
LOCKED => LOCKED_OUT);
CLKIN_IBUFG_INST : IBUFG
port map (
I => CLKIN_IN,
O => CLKIN_IBUFG);
CLK0_BUFG_INST : BUFG
port map (
I => CLK0_BUF,
O => CLKFB_IN);
CLKFX_BUFG_INST : BUFG
port map (
I => CLKFX_BUF,
O => CLKFX_OUT);
CLKIN_IBUFG_OUT <= CLKIN_IBUFG;
CLK0_OUT <= CLKFB_IN;
GND <= '0';
end STRUCT;
Article: 69345Jerzy, Since it sounds like you are cascading two DCMs, you must hold the second DCM in reset until the first has locked. Cascading two DCMs from a CLKFX to a CLKIN to a CLKFX is not recommended, but has been characterized to work under most situations where the jitter from the first DCM does not exceed the requirement of the second DCM. It is not recommended to have a CLKFX out to a CLKIN to a CLK0 (CLKDV, CLK2X) out (use of DLL) as this is a very poor cascade. The CLK0 should always come from the first DCM to the CLKIN of the second DCM which generates the CLKFX (if the frequencies work out). It would be better to just take the 108 MHz from the first DCM and divide it down with a synchronous counter to get the 27 and 54 MHz signals, why use another DCM? This also reduces the jitter as a percentage of the period. Not that I do not appreciate designers using every DCM they can (after all, I was on the team that designed it), the DCM is a short-cut to doing true synchonous design (with clock enables)! Do not forget using the old simple techniques from years past, either. Austin Jerzy wrote: > Hello > I've got following problem: > I need 27MHz and 54MHz clocks, input freq. is 20MHz. > Till today I used DCM FS 27/20 next to DLL and DLL*2. > Theoreticly it should works OK, but doesn't. From time to time after > reboot or after clok stop, it works strange and completly bad. Today > I've read about jitter on output of DCM's CLKFX, I check on "Virtex-II > CLKFX Jitter Calculator" that in this conditions I have over 2 ns > jitter on CLKFX output, which is to big for DLL input CLKIN. > So I try to do this way: > DCM FS 27/5 - I have 108MHz next to DLL/4 and DLL*2 > The jitter on CLKFX should be below 1ns and now it must work but > doesn't. > What should I check else? > Please help me, I lose my hair :> > > Best regards > Jerzy GburArticle: 69346
"Jon Beniston" <jon@beniston.com> wrote in message news:e87b9ce8.0405070500.7c9c4bcc@posting.google.com... > > Also, what's the status of open source tools? (I like to tinker on > > the software end of things, too, and I have a bad case of PowerBook > > envy, and I haven't seen any software available other than x86 and > > big-iron UNIX). Can they go from VHDL/Verilog all the way to > > downloading the file to the chip? I see that compilation (Icarus > > verilog) and downloading (found it in this group's FAQ) work, but what > > about place and route? Icarus' docs say it's a no-go for this; is > > there anything else, or must I use the Xilinx tools? (I guess I have > > a Xilinx bias -- it's all I've used, and I don't see much else for > > cheap development boards.) > > Why bother with Open Source stuff when various incarnations of > commerical tools are free to use? Check out for the Xilinx WebPack: > > http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack > I think you misunderstand the point of Open Source - price is only one aspect (and open source software is not necessarily free, although normally you can find any given open source program somewhere for free downloading. Frequently you can buy pre-packaged CD's, often with support, such as Linux distributions or the OpenTech cdrom http://www.opencores.org/projects.cgi/web/opentech/about ). The original poster was looking for open source tools because he likes to tinker with the software, and because he wants to run the software on something other than an x86 machine. That is possible with open source software, but not with free closed source software. Sites worth looking at are http://www.opencores.org , http://opencollector.org/ , and http://geda.seul.org . But as another poster pointed out, there are good reasons why place and route software tends to be proprietry.Article: 69347
Petter Gustad <newsmailcomp5@gustad.com> wrote in message news:<m3hdus1zjr.fsf@scimul.dolphinics.no>... > "Kenneth Land" <kland1@neuralog1.com1> writes: > > > Anyone know if there are any gotcha's with working with multiple Quartus (II > > v. 4) projects on the same computer? > > > > I'd like to work several approaches simultaneously, but not if there are > > side effects - subtle or otherwise. > > I naver had any problem with multiple projects and Quartus under Linux > and Solaris at least. However, I'm using mostly scripts in my flow, > and minimal amount of GUI. > > Petter I've got several projects running in Quartus with no porblems. The problem/opportunity you will come across is when an upgrade to Quartus is released. Upgrading could cause you to recompile old projects and perhaps changing something by surprise. GeorgeArticle: 69348
Peter,
> Yes I would love to participate in the VHDL-200X effort. It's nice to
> see it's open to the non-members. Is there a target release date for
> VHDL-200X?
VHDL-200X is a multi-phased effort.
The first phase is fast-track. These are critical update
items. It is due to have ready for ballot some time this
year. Details on this are at:
http://www.eda.org/vhdl-200x/vhdl-200x-ft
There are things that will go out with FT that are not on
the FT proposal list. These are items from the other
groups that are working them as separate issues.
> This problem of the fields of a record appearing to be resolved as a
> group, and not individually, is particularly vexing to me. Hopefully I
> won't have to deal with it in the next VHDL version.
It has been vexing me too. I don't think we will have the
solution for fast track, however, it is one of my high
priorities so I will be pushing for it making the revision
that follows fast track.
Cheers,
Jim
>>Peter,
>>As a PS to my other post, to date I have found
>>that if I want to work with a single record,
>>I have been limited to std_logic family.
>>
>>I have tried tinkering with integers and resolution
>>functions, but have had problems with resolving a value
>>to drive when the record field is not to be driven.
>>It seems that the resolution function is called at the
>>block level and there currently no way I could find to
>>work around this.
>>
>>This is a topic we are kicking around in the VHDL-200X
>>effort. I had wished for it to be part of the fast track
>>effort and I made a proposal, but it is not clear even to
>>me that the proposal is the best long term solution, so I
>>don't want to push it. My preference is to see what comes
>>up when we give more time and consideration to the problem.
>>
>>For more on the vhdl-200x effort, see:
>> http://www.eda.org/vhdl-200x
>>
>>IEEE standards are open to public participation.
>>
>>Best Regards,
>>Jim
>>
>>
>>
>>>Hi Mike,
>>>
>>>Yes I found my problem, and it was unfortunately in a part of my
>>>record that I didn't post. In my record, I had a field that was of the
>>>physical type time which I was using inside my procedures for certain
>>>delays. ie:
>>>
>>> type rec is record
>>> ...
>>> clock_period : time;
>>> ...
>>> end record;
>>>
>>>So while I was assuming a signal-driving issue to be the problem, it
>>>was this field (which is still bizarre, because I set this field only
>>>once and never write it again, therefore, I would have thought, it
>>>could not be a problem). Anyways, I replaced this field with a clock
>>>signal which makes more sense now anyways and everything works great,
>>>and thanks to yours and Jim's replies, I understand what's going on
>>>much better too. I had better post the whole thing the next time I
>>>have a problem like this.
>>>
>>>-- Pete
>>>
>>>
>>>
>>>>Peter Sommerfeld wrote:
>>>>
>>>>
>>>>
>>>>>Thanks for the reply. I must be on the right track, because it looks
>>>>>like I have been doing what you suggested in
>>>>>http://groups.google.com/groups?q=gaggle.DSPaddr. However, the InitBus
>>>>>call causes compile errors in my design.
>>>>
>>>>You have stumbled onto the procedure scope problem.
>>>>Re-read that thread and see the lines I added
>>>>to my example architecture below.
>>>>
>>>> -- Mike Treseler
>>>>
>>>>
>>>>------------------------------------------------------------
>>>>architecture synth of signal_structure is
>>>> -- note, I changed your type to data in and out signals
>>>>
>>>> type DSPIF_type is
>>>> record
>>>> DSPaddr : std_logic_vector(23 downto 0);
>>>> DSPdata_in : std_logic_vector(31 downto 0);
>>>> DSPdata_out : std_logic_vector(31 downto 0);
>>>> nDHOLD : std_logic;
>>>> nDHOLDA : std_logic;
>>>> nDPAGE : std_logic_vector(3 downto 0);
>>>> nDSTRB : std_logic;
>>>> nDBE : std_logic_vector(3 downto 0);
>>>> nDOE : std_logic;
>>>> nDWE : std_logic;
>>>> nDRDY : std_logic;
>>>> end record;
>>>>
>>>> signal gaggle : DSPIF_type;
>>>> signal output_enabled : boolean;
>>>>-------------------------------------------------------------------------------
>>>> -- Added proc example in scope
>>>> procedure InitBus( signal gaggle: inout DSPIF_type )
>>>> is begin end InitBus;
>>>>-------------------------------------------------------------------------------
>>>>begin
>>>> -- wire up signal structure to pins
>>>> gaggle.DSPaddr <= DSPaddr;
>>>> gaggle.DSPdata_in <= DSPdata;
>>>>-- . . . (rest of INs go here)
>>>>-- then OUTs:
>>>> nDHOLD <= gaggle.nDRDY;
>>>> nDRDY <= gaggle.nDRDY;
>>>> DSPdata <= gaggle.DSPdata_out when output_enabled
>>>> else (DSPdata'range => 'Z');
>>>>
>>>>-- processes using the gaggle signals go here
>>>>
>>>>end architecture synth;
>>>>
>>>>
>>>> -- Mike Treseler
>>
>>
>>--
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>Jim Lewis
>>Director of Training mailto:Jim@SynthWorks.com
>>SynthWorks Design Inc. http://www.SynthWorks.com
>>1-503-590-4787
>>
>>Expert VHDL Training for Hardware Design and Verification
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Article: 69349What's going on at Altera!?!? I've tried a few times to call the tech support line over the last couple of weeks. Each time I just end up on hold forever. One time, with my speakerphone, I waiting over an hour before giving up. I don't want to enter the problem on the on-line mysupport page, since I know that will take a couple of days for a response. I had been calling a direct contact in the company, but he appears to be out today. Is there anyone there? I have a Signal Probe problem I need resolved ASAP! If there's someone at Altera reading this, please contact me at david.rogoff@emulex.com. Thanks, David p.s. - The tech support line is also very annoying that it makes you listen to the very long intro message warning that you must use your Altera ID number and won't let you bypass the message. Please fix it!
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