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
Jui Tan <juitongtanSPAM@yahoo.com> wrote: > 2 weeks ago, I decided to upgrade my tools to version 4.1. After the > upgrade, I ran the same design through version 4.1 and got a whole list of > timing violations (some constraints are violated due to gate delays alone). > I called the Xilinx tech hotline, and they said that the timing library for > version 4.1 reflects the characteristics of the latest silicon. He told me Yep. The newer software has newer (hopefully more accurate) timing data. The speed files change quite regularly, even between service packs. > I am sure I am not the only person with this problem. If you have a virtexE > design in production PAR with ISE 3.3, what have/would you do? The Virtex-E speed files are still changing. The 4.1i service pack 3 release has v1.65 of the Virtex-E speed files, and there's some more slow downs in those (CLB RAM setup time, from memory). A previous version slowed down some block RAM control inputs. The 3.3 service pack 8 speed files doubled the block RAM clock-to-out delay. So you have a Virtex-E design which meets timing in 3.3 and works in all of your testing with the devices you have. So do you make the effort to get it to meeting timing with the newer speed data? Good question. I think of it this way -- the speed files reflect what the silicon could be, at worst. That your design works on the silicon you have unfortunately isn't proof that it will work on every part that you ever ship. Theoretically Xilinx could actually change the silicon to match pessimistic speed files if that would improve yield, product cost etc. So, I've spent the last week updating some old designs and I'll be spending most of next week on it too. Not much fun but necessary. (Actually, there is some real design work to be done so we're upgrading to the last speed files at the same time -- we don't generally re-route designs just for new timing data.) Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 39401
"Mike Johnson" <mikej <NOSPAM>freeuk.com> wrote: > In the past I've generally found that the speed files have become less > pessimistic as Xilinx have refined them, so the chips 'get faster'. No > excuse for this though as I thought 3.3 sp8 virtexE speedfiles were final ? No, there are updates for Virtex-E as recently as 4.1 SP3 (v1.65 speed files). I would say that in almost every release of the Virtex-E speed files in the past year, some part of the device has gotten slower. I haven't seen any speed ups. Routes that were easy 18 months ago are killers these days. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 39402
Hi Philip,
I had a feeling that it was going to be bitstream-only configurable
but you have confirmed it for me. Shame really, but we will have to
go with an external single-chip programmable clockgen then, as we
do need the ability to sweep through a range of frequencies from
under the Vertex's control.
Thanks very much for your help.
Best regards,
Tim Ottley
"Philip Freidin" <philip@fliptronics.com> wrote in message
news:1ni76ugsrmn4i936l9r7vm64rfl2pf89l8@4ax.com...
> On Fri, 8 Feb 2002 09:34:38 -0000, "Tim Ottley" <tim.ottley@elixent.com>
wrote:
> >Hi Peter et al,
> >
> >I wish to use a DCM as a programmable and sweepable clock source
> >within a Vertex2 device. It will only be supplying its output to an
> >external pin,
> >but the output will need to be gatable.
> >
> >I want to use it in the Digital Frequency Synthesis mode, with registers
to
> >hold
> >the Multiplier & Divider values so that the output frequency can be
changed
> >at
> >any time. The only problem I have is that I cannot find the M & D
control
> >signals
> >on the instance of the DCM block. I believe that I will need to use the
> >CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it
> >is instanced, but I am not clear how I can use these in a dynamically
> >adjustable way.
> >
> >Can anyone tell me if this is possible, and if so, a little snippet of
> >Verilog to illustrate?
> >(pretty please)
> >
> >Thanks,
> > Tim Ottley.
> >
>
> This is do-able, but FAR from easy. The M and D values are parameters
> that end up being encoded in the bit stream. There is no direct runtime
> access to them.
>
> The Virtex-II devices do support run-time partial configuration.
>
> You would need to find the location of these bits in the bitstream,
> and create a partial reconfig to modify them on the fly. Given the
> issues with DCM reset, I would suspect that to be succesful, you would
> need to assert the DCM reset, then do the reconfig, then release DCM
> reset. Since configuration is by frames, you would also have to build
> reconfiguration frames that did not damage other parts of your design.
>
> So I dont think that sweeping is going to be possible.
>
> To see what you are up against, create a design with a DCM in it.
> and create an RBT file from it. Using the XDL interface to the
> NCD file, edit the M and D, convert back to NCD and create a new
> RBT. Compare to see how it changed.
>
> In the XDL, look for something like this:
>
> inst "dcm_0" "DCM" , placed TIOIBRAMC1 DCM_X0Y1 ,
> cfg "DLL_FREQUENCY_MODE::LOW DFS_FREQUENCY_MODE::LOW
> STARTUP_WAIT::#OFF DUTY_CYCLE_CORRECTION::TRUE
> FACTORY_JF2::0X80 FACTORY_JF1::0XC0 CLKDV_DIVIDE::2
> FREEZEDLLINV::#OFF FREEZEDFSINV::#OFF STSADRS0INV::#OFF
> STSADRS1INV::#OFF STSADRS2INV::#OFF STSADRS3INV::#OFF
> PSCLKINV::PSCLK PSENINV::PSEN PSINCDECINV::PSINCDEC
> RSTINV::RST DSSENINV::DSSEN_B CTLOSC2INV::#OFF
> CTLOSC1INV::#OFF CTLGOINV::#OFF CTLSEL0INV::#OFF
> CTLSEL1INV::#OFF CTLSEL2INV::#OFF CTLMODEINV::#OFF
> CLK_FEEDBACK::1X CLKOUT_PHASE_SHIFT::VARIABLE
> CLKIN_DIVIDE_BY_2::#OFF VERY_HIGH_FREQUENCY::#OFF
> DSS_MODE::NONE DCM:dcm_0: CLKFX_DIVIDE::1 CLKFX_MULTIPLY::4
> PHASE_SHIFT::0 LL_HEX_DLLS:: LL_HEX_DLLC:: LL_HEX_DFS::
> LL_HEX_COM:: LL_HEX_MISC::"
>
>
> M and D are on the third last line. BUT ... there seems to be
> quite a few other attributes that are being automatically set
> by the sw, that are not documented for user control.
>
> The command I used to create the above was:
>
> xdl -ncd2xdl app_1.ncd
>
> I am using M4.1i sp3
>
> Good luck,
>
> Philip Freidin
>
>
> Philip Freidin
> Fliptronics
Article: 39403
"Josan Moreno" <joseanmo@unex.es> wrote in message
news:a3uh7l$qjh$1@emilio.unex.es...
> Hi,
> I'm looking for an RTL description or PLI module of the 8051 included in
> Triscend for simulation purposes.
> Thanks.
Josan,
What's wrong with contacting Triscend for this product?
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
Article: 39404Hi everyone I am using synplify pro 6.2.4 to synthesis, after synthesis, I use the .vm file and the quartus II 1.1 library file to perform post syn simulation, but it seems that all register do not change even the simulation time progress forward for a long time. it seems that the external clock can not enter the design why? BTW : I uncheck the "disable io insertion" option in synplify,I think this may be the cause.Article: 39405
Hi I am using synplify pro 6.2.4 to synthesis, after synthesis, I use the .vm file and the quartus II 1.1 library file to perform post syn simulation in modelsim, but it seems that all register do not change even the simulation time progress forward for a long time. it seems that the external clock can not enter the design why? BTW : I uncheck the "disable io insertion" option in synplify,I think this may be the cause. and about the warning, there are following warning 1 some output pin have undriven bit 2 many many many register have been removed or stuck at a fix value amd about the replace, in the synthesis , the syntheser have optimize across the border of module,how to deal with this kayrock66@yahoo.com (Jay) wrote in message news:<d049f91b.0202061722.56bb6195@posting.google.com>... > If you are new at using HDL's to design ciruits, it is very possible > you have coded something that will not behave the same in gates (post > synthesis) as it does in RTL form. Often time the sythesizer will > warn you of these coding style issues, but not always. You should run > a post syth, pre P&R simulation against you existing test-bench and > see if it flys. If it doesn't you, among other techniques, you can > replace on by one, each module with its RTL version until you make it > work. > > Good luck to you! > > shengyu_shen@hotmail.com (ssy) wrote in message news:<f4a5f64f.0201310054.234aa10f@posting.google.com>... > > Hi every one > > > > I am using sopc board from altera, it hold an APEX20k400E, I am using > > synplicity 6.2.4 to synthesis and then use quartus II 1.1 to P&R, > > > > my design is an cpu, the cpu hold one cpu core(design by me), an > > interconnect network(design by other), and some slave device(design by > > my team member) > > > > the cpu core have two master port to fetch instruction and data > > > > the interconnect network have 8 master and 16 slave, any unuse port's > > output pin will not connect and input pin will assign 0, > > > > I run pre syn rtl simulation, all ok,but after burn on the board, it > > is error, > > > > I want to know possible cause of synthesis/simulation mismatch.Article: 39406
hamish@cloud.net.au wrote: > "Mike Johnson" <mikej <NOSPAM>freeuk.com> wrote: > > In the past I've generally found that the speed files have become less > > pessimistic as Xilinx have refined them, so the chips 'get faster'. No > > excuse for this though as I thought 3.3 sp8 virtexE speedfiles were final ? > > No, there are updates for Virtex-E as recently as 4.1 SP3 (v1.65 speed > files). I would say that in almost every release of the Virtex-E speed > files in the past year, some part of the device has gotten slower. > I haven't seen any speed ups. Routes that were easy 18 months ago > are killers these days. > > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au> Hamish. Thanks for this message - I was just about to download SP3!Article: 39407
[...] OK, let me summarize to see if I got everything correct: 1. From a uniformly distributed sequence of n-bit numbers one can generate a non-uniformly distributed single-bitstream by squashing the n-bit by a comparator, allowing for densities to be chosen from 0 to 1 in 1/2^n increments. Interestingly (and in relation to my original question) this seems to mean that I can partition the n-bit into (j+k)-bit and obtain 2^j completely uncorrelated sequences in 1/2^k increments and densities ranging from 0 to 1/2^j by using 2^j two-sided comparators with non-overlapping ranges. Using the binary partition scheme from above that simplifies to just a one-sided comparator in k bits and a decoder that enables/disables the output based on j bits. 2. Pseudorandom n-bitstreams may be produced in various ways, which relate to polynomials in GF2 (esp. CRC polynomials). A parallel output can be implemented by unrolling and pipelining an LFSR for instance or you may just go for the polynomial directly. (I seem to remember that some/most of these polynomials are cryptographically weak, but that isn't an issue for the application I have in mind. I just need a white spectrum.) Achim.Article: 39408
I'm after an WinNT/2K Parallel port driver so I can realise a Flash based FPGA config data store. I'd prefer free or share ware but a modest cost wouldn't be out of the question. Could someone point me in the right direction ?Article: 39409
Hi All, I have some problems finding a good design practice for a bus-interface. We have a processor running internally at 100Mhz, and externally at 50Mhz (2 internal bus cycles used for 1 complete external bus cycle). Now the addresses are set, the cs lines are set, the re_n and we_n signals are set and the data is set or read. I know all the timing variables on these lines. Now i need to design a bus interface, but i want the internal clock to run at least at 66 Mhz because i need to access ram at this speed and want to keep the internal clock speeds at the same speed. Now how can i best trigger my internal signals, the we_n line goes active low after 8 nsecs of valid data, should i use this signal and feed it into a fflop to trigger on, or should i let the flop trigger at the internal clock speed and detect that the line has changed state and take action from there, or should i make the desing completely combinatorial? Thanks in advance, Richard -- Quest Innovations tel: +31 (0) 227 604046 fax: +31 (0) 227 604053 http://www.quest-innovations.comArticle: 39410
Rick Filipkiewicz wrote: > I'm after an WinNT/2K Parallel port driver so I can realise a Flash > based FPGA config data store. > > I'd prefer free or share ware but a modest cost wouldn't be out of the > question. Could someone point me in the right direction ? One package is the DriverLINX software and driver. Check for it at www.sstnet.com. We also have an installation file for it (port95nt.exe) at http://www.xess.com/ho07000.html. Another option is UNIIO. The source for this is completely available so you can compile the parts you need. Look for it at www.bbdsoft.com. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 39411
But do you really need the DCM to do all the work? If you can tolerate jitter - if - then there may be a way to get your clock generation capability without using an external solution. The global clock mux is a wonderful little primitive in the Virtex-II which can give glitchless transitions from one clock to another. Consider 1) producing a high frequency clock with the DCM(s), 2) using several phase-shifted versions of the same clock (1/4 cycle intervals, perhaps), 3) using the DDR interface to give you beautiful edges, 4) using an accumulator based scheme to transition between phase offsets. If you need a wide range of frequencies (>12% ?) this approach probably won't do you much good but if your frequency range is tight, adding a phase offset of 1/8 cycle of the DCM frequency can produce some beautiful time-domain results. Frequency domain results would be a bit choppy since you're applying a quantized phase-modulation technique to get your output. It's a bit of work compared to wiring up a PLL chip but if you need the most compact implementation this technique can be your friend. - John_H Tim Ottley wrote: > Hi Philip, > > I had a feeling that it was going to be bitstream-only configurable > but you have confirmed it for me. Shame really, but we will have to > go with an external single-chip programmable clockgen then, as we > do need the ability to sweep through a range of frequencies from > under the Vertex's control. > > Thanks very much for your help. > > Best regards, > Tim Ottley > > "Philip Freidin" <philip@fliptronics.com> wrote in message > news:1ni76ugsrmn4i936l9r7vm64rfl2pf89l8@4ax.com... > > On Fri, 8 Feb 2002 09:34:38 -0000, "Tim Ottley" <tim.ottley@elixent.com> > wrote: > > >Hi Peter et al, > > > > > >I wish to use a DCM as a programmable and sweepable clock source > > >within a Vertex2 device. It will only be supplying its output to an > > >external pin, > > >but the output will need to be gatable. > > > > > >I want to use it in the Digital Frequency Synthesis mode, with registers > to > > >hold > > >the Multiplier & Divider values so that the output frequency can be > changed > > >at > > >any time. The only problem I have is that I cannot find the M & D > control > > >signals > > >on the instance of the DCM block. I believe that I will need to use the > > >CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it > > >is instanced, but I am not clear how I can use these in a dynamically > > >adjustable way. > > > > > >Can anyone tell me if this is possible, and if so, a little snippet of > > >Verilog to illustrate? > > >(pretty please) > > > > > >Thanks, > > > Tim Ottley. > > > > > > > This is do-able, but FAR from easy. The M and D values are parameters > > that end up being encoded in the bit stream. There is no direct runtime > > access to them. > > > > The Virtex-II devices do support run-time partial configuration. > > > > You would need to find the location of these bits in the bitstream, > > and create a partial reconfig to modify them on the fly. Given the > > issues with DCM reset, I would suspect that to be succesful, you would > > need to assert the DCM reset, then do the reconfig, then release DCM > > reset. Since configuration is by frames, you would also have to build > > reconfiguration frames that did not damage other parts of your design. > > > > So I dont think that sweeping is going to be possible. > > > > To see what you are up against, create a design with a DCM in it. > > and create an RBT file from it. Using the XDL interface to the > > NCD file, edit the M and D, convert back to NCD and create a new > > RBT. Compare to see how it changed. > > > > In the XDL, look for something like this: > > > > inst "dcm_0" "DCM" , placed TIOIBRAMC1 DCM_X0Y1 , > > cfg "DLL_FREQUENCY_MODE::LOW DFS_FREQUENCY_MODE::LOW > > STARTUP_WAIT::#OFF DUTY_CYCLE_CORRECTION::TRUE > > FACTORY_JF2::0X80 FACTORY_JF1::0XC0 CLKDV_DIVIDE::2 > > FREEZEDLLINV::#OFF FREEZEDFSINV::#OFF STSADRS0INV::#OFF > > STSADRS1INV::#OFF STSADRS2INV::#OFF STSADRS3INV::#OFF > > PSCLKINV::PSCLK PSENINV::PSEN PSINCDECINV::PSINCDEC > > RSTINV::RST DSSENINV::DSSEN_B CTLOSC2INV::#OFF > > CTLOSC1INV::#OFF CTLGOINV::#OFF CTLSEL0INV::#OFF > > CTLSEL1INV::#OFF CTLSEL2INV::#OFF CTLMODEINV::#OFF > > CLK_FEEDBACK::1X CLKOUT_PHASE_SHIFT::VARIABLE > > CLKIN_DIVIDE_BY_2::#OFF VERY_HIGH_FREQUENCY::#OFF > > DSS_MODE::NONE DCM:dcm_0: CLKFX_DIVIDE::1 CLKFX_MULTIPLY::4 > > PHASE_SHIFT::0 LL_HEX_DLLS:: LL_HEX_DLLC:: LL_HEX_DFS:: > > LL_HEX_COM:: LL_HEX_MISC::" > > > > > > M and D are on the third last line. BUT ... there seems to be > > quite a few other attributes that are being automatically set > > by the sw, that are not documented for user control. > > > > The command I used to create the above was: > > > > xdl -ncd2xdl app_1.ncd > > > > I am using M4.1i sp3 > > > > Good luck, > > > > Philip Freidin > > > > > > Philip Freidin > > FliptronicsArticle: 39412
Now that you know some of the timing numbers are worse you can skip downloading the update and your parts won't run slower! ( ? ) Rick Filipkiewicz wrote: > hamish@cloud.net.au wrote: > > > "Mike Johnson" <mikej <NOSPAM>freeuk.com> wrote: > > > In the past I've generally found that the speed files have become less > > > pessimistic as Xilinx have refined them, so the chips 'get faster'. No > > > excuse for this though as I thought 3.3 sp8 virtexE speedfiles were final ? > > > > No, there are updates for Virtex-E as recently as 4.1 SP3 (v1.65 speed > > files). I would say that in almost every release of the Virtex-E speed > > files in the past year, some part of the device has gotten slower. > > I haven't seen any speed ups. Routes that were easy 18 months ago > > are killers these days. > > > > Hamish > > -- > > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au> > > Hamish. > > Thanks for this message - I was just about to download SP3!Article: 39413
Tim, There is someone out here (I can't remember who) who is going to use the ICAP feature, and reconfigure the bits he needs for different M and D values. The ICAP is a two for one mux that switches all of the config pins outside the part, to inside the part, for use internally. Use bitgen -r name1 name2 to get a diff stream that is just the differences between the two streams to reconfigure what you want. Put the diff streams in a BRAM, or external part, and either use ICAP, or external reconfig to change M and D. You MUST reset the DCM after reconfig. Austin Tim Ottley wrote: > Hi Philip, > > I had a feeling that it was going to be bitstream-only configurable > but you have confirmed it for me. Shame really, but we will have to > go with an external single-chip programmable clockgen then, as we > do need the ability to sweep through a range of frequencies from > under the Vertex's control. > > Thanks very much for your help. > > Best regards, > Tim Ottley > > "Philip Freidin" <philip@fliptronics.com> wrote in message > news:1ni76ugsrmn4i936l9r7vm64rfl2pf89l8@4ax.com... > > On Fri, 8 Feb 2002 09:34:38 -0000, "Tim Ottley" <tim.ottley@elixent.com> > wrote: > > >Hi Peter et al, > > > > > >I wish to use a DCM as a programmable and sweepable clock source > > >within a Vertex2 device. It will only be supplying its output to an > > >external pin, > > >but the output will need to be gatable. > > > > > >I want to use it in the Digital Frequency Synthesis mode, with registers > to > > >hold > > >the Multiplier & Divider values so that the output frequency can be > changed > > >at > > >any time. The only problem I have is that I cannot find the M & D > control > > >signals > > >on the instance of the DCM block. I believe that I will need to use the > > >CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it > > >is instanced, but I am not clear how I can use these in a dynamically > > >adjustable way. > > > > > >Can anyone tell me if this is possible, and if so, a little snippet of > > >Verilog to illustrate? > > >(pretty please) > > > > > >Thanks, > > > Tim Ottley. > > > > > > > This is do-able, but FAR from easy. The M and D values are parameters > > that end up being encoded in the bit stream. There is no direct runtime > > access to them. > > > > The Virtex-II devices do support run-time partial configuration. > > > > You would need to find the location of these bits in the bitstream, > > and create a partial reconfig to modify them on the fly. Given the > > issues with DCM reset, I would suspect that to be succesful, you would > > need to assert the DCM reset, then do the reconfig, then release DCM > > reset. Since configuration is by frames, you would also have to build > > reconfiguration frames that did not damage other parts of your design. > > > > So I dont think that sweeping is going to be possible. > > > > To see what you are up against, create a design with a DCM in it. > > and create an RBT file from it. Using the XDL interface to the > > NCD file, edit the M and D, convert back to NCD and create a new > > RBT. Compare to see how it changed. > > > > In the XDL, look for something like this: > > > > inst "dcm_0" "DCM" , placed TIOIBRAMC1 DCM_X0Y1 , > > cfg "DLL_FREQUENCY_MODE::LOW DFS_FREQUENCY_MODE::LOW > > STARTUP_WAIT::#OFF DUTY_CYCLE_CORRECTION::TRUE > > FACTORY_JF2::0X80 FACTORY_JF1::0XC0 CLKDV_DIVIDE::2 > > FREEZEDLLINV::#OFF FREEZEDFSINV::#OFF STSADRS0INV::#OFF > > STSADRS1INV::#OFF STSADRS2INV::#OFF STSADRS3INV::#OFF > > PSCLKINV::PSCLK PSENINV::PSEN PSINCDECINV::PSINCDEC > > RSTINV::RST DSSENINV::DSSEN_B CTLOSC2INV::#OFF > > CTLOSC1INV::#OFF CTLGOINV::#OFF CTLSEL0INV::#OFF > > CTLSEL1INV::#OFF CTLSEL2INV::#OFF CTLMODEINV::#OFF > > CLK_FEEDBACK::1X CLKOUT_PHASE_SHIFT::VARIABLE > > CLKIN_DIVIDE_BY_2::#OFF VERY_HIGH_FREQUENCY::#OFF > > DSS_MODE::NONE DCM:dcm_0: CLKFX_DIVIDE::1 CLKFX_MULTIPLY::4 > > PHASE_SHIFT::0 LL_HEX_DLLS:: LL_HEX_DLLC:: LL_HEX_DFS:: > > LL_HEX_COM:: LL_HEX_MISC::" > > > > > > M and D are on the third last line. BUT ... there seems to be > > quite a few other attributes that are being automatically set > > by the sw, that are not documented for user control. > > > > The command I used to create the above was: > > > > xdl -ncd2xdl app_1.ncd > > > > I am using M4.1i sp3 > > > > Good luck, > > > > Philip Freidin > > > > > > Philip Freidin > > FliptronicsArticle: 39414
PS: Peter is out on a secret mission, so he may or may not answer as he reaches civilized locations. Expect him to travel electronically under an alias. Austin Austin Lesea wrote: > Tim, > > There is someone out here (I can't remember who) who is going to use the ICAP > feature, and reconfigure the bits he needs for different M and D values. > > The ICAP is a two for one mux that switches all of the config pins outside the > part, to inside the part, for use internally. > > Use bitgen -r name1 name2 to get a diff stream that is just the differences > between the two streams to reconfigure what you want. > > Put the diff streams in a BRAM, or external part, and either use ICAP, or > external reconfig to change M and D. > > You MUST reset the DCM after reconfig. > > Austin > > Tim Ottley wrote: > > > Hi Philip, > > > > I had a feeling that it was going to be bitstream-only configurable > > but you have confirmed it for me. Shame really, but we will have to > > go with an external single-chip programmable clockgen then, as we > > do need the ability to sweep through a range of frequencies from > > under the Vertex's control. > > > > Thanks very much for your help. > > > > Best regards, > > Tim Ottley > > > > "Philip Freidin" <philip@fliptronics.com> wrote in message > > news:1ni76ugsrmn4i936l9r7vm64rfl2pf89l8@4ax.com... > > > On Fri, 8 Feb 2002 09:34:38 -0000, "Tim Ottley" <tim.ottley@elixent.com> > > wrote: > > > >Hi Peter et al, > > > > > > > >I wish to use a DCM as a programmable and sweepable clock source > > > >within a Vertex2 device. It will only be supplying its output to an > > > >external pin, > > > >but the output will need to be gatable. > > > > > > > >I want to use it in the Digital Frequency Synthesis mode, with registers > > to > > > >hold > > > >the Multiplier & Divider values so that the output frequency can be > > changed > > > >at > > > >any time. The only problem I have is that I cannot find the M & D > > control > > > >signals > > > >on the instance of the DCM block. I believe that I will need to use the > > > >CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it > > > >is instanced, but I am not clear how I can use these in a dynamically > > > >adjustable way. > > > > > > > >Can anyone tell me if this is possible, and if so, a little snippet of > > > >Verilog to illustrate? > > > >(pretty please) > > > > > > > >Thanks, > > > > Tim Ottley. > > > > > > > > > > This is do-able, but FAR from easy. The M and D values are parameters > > > that end up being encoded in the bit stream. There is no direct runtime > > > access to them. > > > > > > The Virtex-II devices do support run-time partial configuration. > > > > > > You would need to find the location of these bits in the bitstream, > > > and create a partial reconfig to modify them on the fly. Given the > > > issues with DCM reset, I would suspect that to be succesful, you would > > > need to assert the DCM reset, then do the reconfig, then release DCM > > > reset. Since configuration is by frames, you would also have to build > > > reconfiguration frames that did not damage other parts of your design. > > > > > > So I dont think that sweeping is going to be possible. > > > > > > To see what you are up against, create a design with a DCM in it. > > > and create an RBT file from it. Using the XDL interface to the > > > NCD file, edit the M and D, convert back to NCD and create a new > > > RBT. Compare to see how it changed. > > > > > > In the XDL, look for something like this: > > > > > > inst "dcm_0" "DCM" , placed TIOIBRAMC1 DCM_X0Y1 , > > > cfg "DLL_FREQUENCY_MODE::LOW DFS_FREQUENCY_MODE::LOW > > > STARTUP_WAIT::#OFF DUTY_CYCLE_CORRECTION::TRUE > > > FACTORY_JF2::0X80 FACTORY_JF1::0XC0 CLKDV_DIVIDE::2 > > > FREEZEDLLINV::#OFF FREEZEDFSINV::#OFF STSADRS0INV::#OFF > > > STSADRS1INV::#OFF STSADRS2INV::#OFF STSADRS3INV::#OFF > > > PSCLKINV::PSCLK PSENINV::PSEN PSINCDECINV::PSINCDEC > > > RSTINV::RST DSSENINV::DSSEN_B CTLOSC2INV::#OFF > > > CTLOSC1INV::#OFF CTLGOINV::#OFF CTLSEL0INV::#OFF > > > CTLSEL1INV::#OFF CTLSEL2INV::#OFF CTLMODEINV::#OFF > > > CLK_FEEDBACK::1X CLKOUT_PHASE_SHIFT::VARIABLE > > > CLKIN_DIVIDE_BY_2::#OFF VERY_HIGH_FREQUENCY::#OFF > > > DSS_MODE::NONE DCM:dcm_0: CLKFX_DIVIDE::1 CLKFX_MULTIPLY::4 > > > PHASE_SHIFT::0 LL_HEX_DLLS:: LL_HEX_DLLC:: LL_HEX_DFS:: > > > LL_HEX_COM:: LL_HEX_MISC::" > > > > > > > > > M and D are on the third last line. BUT ... there seems to be > > > quite a few other attributes that are being automatically set > > > by the sw, that are not documented for user control. > > > > > > The command I used to create the above was: > > > > > > xdl -ncd2xdl app_1.ncd > > > > > > I am using M4.1i sp3 > > > > > > Good luck, > > > > > > Philip Freidin > > > > > > > > > Philip Freidin > > > FliptronicsArticle: 39415
Does any one have serial drivers for WinNT/2K? I need to get a driver, etc. to allow me to talk to an FPGA based device via the com ports in an NT machine. Dave Vanden Bout wrote: > Rick Filipkiewicz wrote: > > > I'm after an WinNT/2K Parallel port driver so I can realise a Flash > > based FPGA config data store. > > > > I'd prefer free or share ware but a modest cost wouldn't be out of the > > question. Could someone point me in the right direction ? > > One package is the DriverLINX software and driver. Check for it at > www.sstnet.com. We also have an installation file for it (port95nt.exe) > at > http://www.xess.com/ho07000.html. > > Another option is UNIIO. The source for this is completely available so > you > can compile the parts you need. Look for it at www.bbdsoft.com. > > -- > || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || > || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || > || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 39416
I am designing a system with multiple FPGA's. The reason I am using multiple FPGA's is that one of the boards is in a separate location and the third board is duplicated several times in the system. I would like to use modelsim to simulate it with separate FPGA's. My ultimate goal is to use post place and route timings for all devices in one simulation. Is this do-able with modelsim XE/ starter 5.5b? I know that it will be slow but that is not a problem for me. I can allow it to run overnight or over the weekend if need be. Also, I cannot get modelsim to recognize my coregen parts at the behavioral level. How do I get that to work?Article: 39417
Rick Lyons wrote: > > On Thu, 07 Feb 2002 14:14:00 -0500, Jerry Avins <jya@ieee.org> wrote: > > (snipped) > > >I learned about DC attenuation in order to design telegraph lines - aren't > >all curricula outdated? - but nothing goes to waste: DC power > >transmission is big these days, and the math hasn't changed.) > > > >Jerry > > Telegraph lines!! Maybe I was right when I > once posted that you knew Abraham Lincoln personally. > > [-Rick-] Not true! But had he he studied engineering instead of law, I might have used some of his cast-off texts. I know how to build an Alexanderson alternator to generate RF directly with a rotating machine (and I live near the first major installation.) I used to be a whiz at tube design, and there were no courses in logic design, let alone computers when I graduated in 1962 (at age 30). I can design (or at least evaluate a design well enough to avoid being sold garbage) power-station steam turbines -- Keenen and Keyes' "Thermodynamic Properties of Steam" is on my book shelf. I know a Worthington steam-operated boiler-return pump on sight, and I can compound a DC generator any way that's called for. So why not telegraph? At least I got as far as simplex connection to ride a free telegraph line on top of a telephone pair, and simultaneous east-west signaling on a single telegraph wire with a new-fangled "duplex" connection. There's a lot of stuff in there that only seems useless: it gives me shortcuts when thinking about new stuff. It's nice to have learned to design commercial antenna towers, too (down to figuring the rivet patterns), but that has been useful only privately. Jerry -- Engineering is the art of making what you want from things you can get. -----------------------------------------------------------------------Article: 39418
What is the frequency range, step resolution, and jitter requirements for your
swept frequency? If they are not too high, you could use a Direct digital
synthesizer with a high rate clock. Carefully designed you could get the
effective master clock in the high hundreds of MHz in VirtexII.
Tim Ottley wrote:
> Hi Philip,
>
> I had a feeling that it was going to be bitstream-only configurable
> but you have confirmed it for me. Shame really, but we will have to
> go with an external single-chip programmable clockgen then, as we
> do need the ability to sweep through a range of frequencies from
> under the Vertex's control.
>
> Thanks very much for your help.
>
> Best regards,
> Tim Ottley
>
> "Philip Freidin" <philip@fliptronics.com> wrote in message
> news:1ni76ugsrmn4i936l9r7vm64rfl2pf89l8@4ax.com...
> > On Fri, 8 Feb 2002 09:34:38 -0000, "Tim Ottley" <tim.ottley@elixent.com>
> wrote:
> > >Hi Peter et al,
> > >
> > >I wish to use a DCM as a programmable and sweepable clock source
> > >within a Vertex2 device. It will only be supplying its output to an
> > >external pin,
> > >but the output will need to be gatable.
> > >
> > >I want to use it in the Digital Frequency Synthesis mode, with registers
> to
> > >hold
> > >the Multiplier & Divider values so that the output frequency can be
> changed
> > >at
> > >any time. The only problem I have is that I cannot find the M & D
> control
> > >signals
> > >on the instance of the DCM block. I believe that I will need to use the
> > >CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it
> > >is instanced, but I am not clear how I can use these in a dynamically
> > >adjustable way.
> > >
> > >Can anyone tell me if this is possible, and if so, a little snippet of
> > >Verilog to illustrate?
> > >(pretty please)
> > >
> > >Thanks,
> > > Tim Ottley.
> > >
> >
> > This is do-able, but FAR from easy. The M and D values are parameters
> > that end up being encoded in the bit stream. There is no direct runtime
> > access to them.
> >
> > The Virtex-II devices do support run-time partial configuration.
> >
> > You would need to find the location of these bits in the bitstream,
> > and create a partial reconfig to modify them on the fly. Given the
> > issues with DCM reset, I would suspect that to be succesful, you would
> > need to assert the DCM reset, then do the reconfig, then release DCM
> > reset. Since configuration is by frames, you would also have to build
> > reconfiguration frames that did not damage other parts of your design.
> >
> > So I dont think that sweeping is going to be possible.
> >
> > To see what you are up against, create a design with a DCM in it.
> > and create an RBT file from it. Using the XDL interface to the
> > NCD file, edit the M and D, convert back to NCD and create a new
> > RBT. Compare to see how it changed.
> >
> > In the XDL, look for something like this:
> >
> > inst "dcm_0" "DCM" , placed TIOIBRAMC1 DCM_X0Y1 ,
> > cfg "DLL_FREQUENCY_MODE::LOW DFS_FREQUENCY_MODE::LOW
> > STARTUP_WAIT::#OFF DUTY_CYCLE_CORRECTION::TRUE
> > FACTORY_JF2::0X80 FACTORY_JF1::0XC0 CLKDV_DIVIDE::2
> > FREEZEDLLINV::#OFF FREEZEDFSINV::#OFF STSADRS0INV::#OFF
> > STSADRS1INV::#OFF STSADRS2INV::#OFF STSADRS3INV::#OFF
> > PSCLKINV::PSCLK PSENINV::PSEN PSINCDECINV::PSINCDEC
> > RSTINV::RST DSSENINV::DSSEN_B CTLOSC2INV::#OFF
> > CTLOSC1INV::#OFF CTLGOINV::#OFF CTLSEL0INV::#OFF
> > CTLSEL1INV::#OFF CTLSEL2INV::#OFF CTLMODEINV::#OFF
> > CLK_FEEDBACK::1X CLKOUT_PHASE_SHIFT::VARIABLE
> > CLKIN_DIVIDE_BY_2::#OFF VERY_HIGH_FREQUENCY::#OFF
> > DSS_MODE::NONE DCM:dcm_0: CLKFX_DIVIDE::1 CLKFX_MULTIPLY::4
> > PHASE_SHIFT::0 LL_HEX_DLLS:: LL_HEX_DLLC:: LL_HEX_DFS::
> > LL_HEX_COM:: LL_HEX_MISC::"
> >
> >
> > M and D are on the third last line. BUT ... there seems to be
> > quite a few other attributes that are being automatically set
> > by the sw, that are not documented for user control.
> >
> > The command I used to create the above was:
> >
> > xdl -ncd2xdl app_1.ncd
> >
> > I am using M4.1i sp3
> >
> > Good luck,
> >
> > Philip Freidin
> >
> >
> > Philip Freidin
> > Fliptronics
--
--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: 39419Theron Hicks wrote: > > I am designing a system with multiple FPGA's. My ultimate goal > is to use post place and route timings for all devices in one > simulation. Is this do-able with modelsim XE/ starter 5.5b? Modelsim knows nothing about devices other than what you include in the technology library, so I see no reason why that would be a problem. > Also, I cannot get modelsim to recognize my coregen parts at the > behavioral level. How do I get that to work? Coregen parts are not behavioral. They are device specific netlists. The alternative is to write and synthesizer your own core functions. -- Mike TreselerArticle: 39420
The 100MHz out of the Dini board might be tough to do. You could go to a
DDR output where each edge of the output clock is active. Is your input
fixed at 10 MHz, or is 10 MHz just a convenience? Can you source the
pattern generator clock out of the FPGA perhaps, or use a multiplied clock
coming int at say 40 MHz? Without the big picture it is awful hard to
offer solutions that meet the needs of your system. As Jerry Avins' tag
line sometimes says: Engineering is the art of making something you want
out of the things that you have. Perhaps you should take stock of what is
available to you and tailor a solution to fit within your means?
Antonio wrote:
> Hi Ray,
> the problem is synchronization between the data arriving from the
> pattern generator and the clocks that are inside FPGA, my idea to use
> clkdll was to enter inside the FPGA with the clock (25MHz for example)
> associated to the data and coming from the pattern generator, from
> that clock to obtain a 100MHz master clock via the CLKDLL and in this
> way is all synchronized, but 100MHz out of the DINI board seems to be
> not achieved.
> If I choose your schema 40MHz quartz plus clkdll divider, I've the
> problem that this divided frequency, maybe 10MHz is not synchronized
> to the 10 MHz coming from the pattern generator, about this I'm
> studing the opportunity to insert a FIFO which write is driven from
> the pattern generator clock and read is driven from the board reduced
> clock.
> What do you think about this, there's a simple way to obtain the same
> results ??
>
> Antonio
--
--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: 39421
Achim Gratz wrote:
> [...]
>
> OK, let me summarize to see if I got everything correct:
>
> 1. From a uniformly distributed sequence of n-bit numbers one can
> generate a non-uniformly distributed single-bitstream by squashing the
> n-bit by a comparator, allowing for densities to be chosen from 0 to 1
> in 1/2^n increments. Interestingly (and in relation to my original
> question) this seems to mean that I can partition the n-bit into
> (j+k)-bit and obtain 2^j completely uncorrelated sequences in 1/2^k
> increments and densities ranging from 0 to 1/2^j by using 2^j
> two-sided comparators with non-overlapping ranges. Using the binary
> partition scheme from above that simplifies to just a one-sided
> comparator in k bits and a decoder that enables/disables the output
> based on j bits.
Hadn't looked at it that way, but yeah, that sounds about right.
>
>
> 2. Pseudorandom n-bitstreams may be produced in various ways, which
> relate to polynomials in GF2 (esp. CRC polynomials). A parallel output
> can be implemented by unrolling and pipelining an LFSR for instance or
> you may just go for the polynomial directly.
Yep.
>
>
> (I seem to remember that some/most of these polynomials are
> cryptographically weak, but that isn't an issue for the application I
> have in mind. I just need a white spectrum.)
An LFSR by itself is cryptographically weak regardless of the polynomial
because you only need N+1 bits to recover the key and initial state, and
therefore the plain text stream. Nevertheless, LFSRs do fall into the
class of GF2 algorithms.
>
>
> Achim.
--
--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: 39422Hi I'm trying to use the schematic entry (ECS) method in ISE 4.1i to design circuits for the Virtex-II fpga. But when I go to Project - New Source to select the ECS, there are no options for ECS, VHDL, Verilog, etc. in the dialogue box. So I then attempt to create the schematic by first opening the ECS window, but I can't upload the Virtex-II Schematic Library...there is only the XC9500 CPLD library. I'm using the standard version of ISE (not the evaluation version, not WEBPACK) so I don't know what the problem is. I'd appreciate any advice on this matter. Thanks TerryArticle: 39423
I'm surprised, but Virtex-E speedfiles are indeed still marked preliminary. the only diferences I spoted between 3.3.8 and 4.1.03 were in Tdh and Tds (setup / hold for BX & BY inputs on CLB distibuted ram) release 4.1.03i xc600e speedfile 1.65 2001-11-14 Tdh -585 - -495 , Tds 686 - 958 release 3.3.08i xv600e speedfile 1.60 2001-05-08 Tdh -186 - -96 , Tds 469 - 559 Jui, are you using lots of distributed ram elements by any chance? I guess in future more (some?) timing slack will have to be allocated to possible characterisation and process changes. Regards, Mike. <hamish@cloud.net.au> wrote in message news:3c63d91c$0$18472$afc38c87@news.optusnet.com.au... > Jui Tan <juitongtanSPAM@yahoo.com> wrote: > > 2 weeks ago, I decided to upgrade my tools to version 4.1. After the > > upgrade, I ran the same design through version 4.1 and got a whole list of > > timing violations (some constraints are violated due to gate delays alone). > > I called the Xilinx tech hotline, and they said that the timing library for > > version 4.1 reflects the characteristics of the latest silicon. He told me > > Yep. The newer software has newer (hopefully more accurate) timing > data. The speed files change quite regularly, even between service packs. > > > I am sure I am not the only person with this problem. If you have a virtexE > > design in production PAR with ISE 3.3, what have/would you do? > > The Virtex-E speed files are still changing. The 4.1i service pack 3 > release has v1.65 of the Virtex-E speed files, and there's some more > slow downs in those (CLB RAM setup time, from memory). A previous > version slowed down some block RAM control inputs. The 3.3 service > pack 8 speed files doubled the block RAM clock-to-out delay. > > So you have a Virtex-E design which meets timing in 3.3 and works > in all of your testing with the devices you have. So do you > make the effort to get it to meeting timing with the newer speed data? > Good question. I think of it this way -- the speed files reflect what > the silicon could be, at worst. > > That your design works on the silicon you have unfortunately isn't > proof that it will work on every part that you ever ship. Theoretically > Xilinx could actually change the silicon to match pessimistic speed > files if that would improve yield, product cost etc. > > So, I've spent the last week updating some old designs and I'll > be spending most of next week on it too. Not much fun but necessary. > (Actually, there is some real design work to be done so we're > upgrading to the last speed files at the same time -- we don't > generally re-route designs just for new timing data.) > > > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 39424
Starting from a 10MHz clock, you can use Peter's circuit to double to 20MHz, then run the faster clock through the DLL. Still outside limits, but will almost certainly work on the bench - stick to 25MHz in shipping product. Phil Connor wrote > Seriously though a single mention in an entire application note > dedicated to the DLL (XAPP132) would have been nice. > > There is even a helpful section "Design Considerations ...Input Clock" > which says "The DLL can be used with any commercially available > quartz crystal oscillator". A bold claim. > > Interestingly the Vertex has no lower clock limit, so Xilinx tell > me. So it seems it can run down to DC. > > I would bet that Antonio and I are not the only ones to have slipped > up here. > > Anyone else?
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