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
Hi Peter, thanks for your reply I was confident of this method's effectiveness but now I am worried :)) . I have already done a timing analysis in the paper and also the simulation waveforms seem promising. I didnt understand what do you mean when telling me that one of my words arrives early and the other one late. The transmitter sends to my FPGA an external clock (thats the 155MHz clock), a valid signal (1 bit indicating the transmission time period) and of course the 16-bit words that I have to store. Every clock period (~6 ns) I have available in my ports one 16-bit word, I register two sequential words from the in port to a 32-bit register (31->16 the first incoming word, 15->0 the second one). Then , in another 32-bit register I register (2 nd time) the 32-bit word I just "made" which are the BRAM data_in. All the above operations are in a process that has in its sensitivity list the 155 clock. I write to the BRAM at 77MHz using the incoming clock divide by 2 using a DLL. BRAM input signals are assigned in the falling edge of the 77MHz clock so as to be before the rising edge (of the same clock) where the BRAM samples them. The write operations are in another process with the slow clock in its sensitivity list. The timing waveforms of the simulation are the same with the timing analysis in paper but does this is a valid hardware design technique? Thanks for your time and help! Best Regards, Harris p.s: thats a small part of my design. I use DLL because other parts need them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155 MHz and I got many timing errors (floorplanning managed to reduce them but still lot of work to be done) "Peter Alfke" <peter.alfke@xilinx.com> wrote in message news:3C7E621F.1E77A244@xilinx.com... > I suggest you grab pencil and paper and do a clock-by-clock timing analysis. You > will find that your clock-speed reduction buys you nothing, unless you also > double-buffer the data. > One of your words arrives nice and early, the other one late. However you clock > the BRAM, one of the two words has the same old short set-up time... > Double-buffering would help. But Ray has mentioned some neat tricks to avoid the > long set-up time of the control inputs. > > I will get back with more constructive notes. "Gotta run" > > Peter Alfke > =================== > "H.L" wrote: > > > Hello all, > > > > I have a module that accepts 16 bit words at 155MHz and I want to store then > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA) to divide by > > 2 the 155MHz clock as this frequency seems to be pretty high to write in the > > BRAM. So far I think 2 processes are enough to do my job, one operating @ > > 155MHz to accept the 16-bit data and store them in a 32-bit register and the > > another one @ 75MHz to write the content of the 32-bit register in the BRAM. > > I am thinking to assign the BRAM's signals (ENABLE,WRITE,ADDRESS,DATA_IN) in > > the falling edge of the 75MHz clock, the main reason for this is the setup > > time of the BRAMs signals (in this way the address,data are 6 ns before next > > rising edge of the clock where BRAM samples its inputs). My question now :) > > , if one process uses the falling edge of one clock does this causes > > problems to other processes in the design , e.g to processes that use a > > different clock or to processes using the rising edge of the same clock? > > > > Best Regards, > > Harris. >Article: 40176
Hi, I need to multiply a clock from around 44kHz to 11MHz, to be implemented in a Lattice ISP (Programmable Logic) device. Does anyone know of how to implement a clock multiplier in VHDL/Verilog or have any schematics or references? I am considering trying to implement an All-Digital PLL (due to noise considerations I would prefer not use an analogue VCO), does anyone have any idea/know of any references on how to do this? Am I being stupid, or is it possible to implement this without using a high frequency external reference clock? Any help would be greatly appreciated. Colin Bury eeburyc@swan.ac.uk University of Wales SwanseaArticle: 40177
rjshaw@iprimus.com.au (russell) wrote in message news:<c3771dbf.0202260036.edc1b91@posting.google.com>... > >............... > > boring interface of the "Assignment organizer". I cannot assign 500 > > pins clicking with my mouse! > > Yes (in quartus2), open the node-finder, select "pins unassigned", > Named "*", then click "Start" to list all the pins. > > Now open "current assignments" floor-plan, and display the external > package view. Now just drag and drop the pins from the node-finder > window to the pins in the floor-plan window. Maxplus2 could do this, > so any version of quartus probably would too. Ah, ok... when I said "I cannot assign 500 pins clicking with my mouse" it wasn't a kind of complain because I couldn't... I meant that assigning 500 pins with my mouse wouldn't have been a good way to use my time, especially if I have to floorplan more than one time...Article: 40178
Hi Prashant, Firstly I would like to know which software you are using in case of Xilinx devices. Secondly, I would like to see the timing report of 16x16 multiplier on a XC2V250 . Peter too had mentioned something like this--->(<6 ns combinatorial delay, < 4 ns with internal pipeline). Please check again. Regards, SANKET. "Peter Ormsby" <faepete.deletethis@mediaone.net> wrote in message news:<f9Df8.10278$Or3.1089192@typhoon.mn.ipsvc.net>... > Prashant <prashantj@usa.net> wrote in message > news:ea62e09.0202281345.1467d3c2@posting.google.com... > > > I'm trying to implement a 16x16 combinational multiplier in the > > EP20K160E. But the timing simulations seem to take 40-50 ns for a > > single multiply. > > > > Anyone have any ideas, how can I speedup the operation? > ... > > Thanks, > > Prashant > > Prashant, > > If anything, the 20K1500E is going to be slower than the 20K160E. However, > you should be able to get much faster speeds out of your 20K160E than you > are currently seeing. > > Make sure that your inputs and outputs are registered. It takes a > relatively long time for a signal to go between the pins and the FPGA > routing structure, so it's helpful to move the inputs into a register before > running them though the multiplier and then registering the multiplier > outputs before running them off the chip. > > Once you have the inputs and outputs registered, you should be able to get a > multiplier working about 50MHz with no pipeline stages or over 110 MHz with > two stages in a 20K160E. You can use the Megawizard to create a pipelined > multiplier without having to figure out the partial products implementation > yourself. > > Let me know if this doesn't help. > > -Pete-Article: 40179
Hi Ken, Are you using any PLLs outside? If yes, then if you do an environment testing with the "Phil" modified code, you may see that for a particular temperature your design works perfectly. Use a DLL in the FPGA instead.This is just a solution on hunch. Have a good day. SANKET. "Ken Mac" <aeu96186@yahoo.co.uk> wrote in message news:<a5noh4$pj4$1@dennis.cc.strath.ac.uk>... > Phil, > > Your solution did indeed solve the hanging problem - thanks very much for > the code! > > The design now runs for 28 seconds instead of 3 for some other reason but I > am sure I can track this down now I can make changes to my VHDL without > random state hangs happening! > > Thanks again, > > KenArticle: 40180
This is a multi-part message in MIME format. --------------FCD48B0226BC6BA3B7F0117E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Phil, How do you know that it will outperform any Virtex2 device? They aren't even out yet, so any speed file that is being used that is simply based on extensive spice simulation is not something I would recommend using for production devices. Dave phil wrote: > Hi, > > you should not expect that the multiplication wil be calculated faster when using the 1500E. the reason is that the die size of the 1500E is larger than the one of the 160E. Therefore, used LEs are likely to spread over the (larger) die and, therefore, performance will be worse. I would recommend to: > > 1. Use the Megawizard to implement the multiplication. > 2. To use a sophisticated synthesys tool such as Synplicitys Synplify to implement the multiplication (just describe a*b, add as many register as you can allow (Synplify will use them as pipeline stages). > 3. Use Synplicitys Amplify to add physical constraints. > 4. Use Alteras Logic Lock to add physical constraints. > 5. Use Alteras new Stratix family of devices which would outperform any Virtex 2 or APEX device. > > regards > > PhilArticle: 40181
For a digital PLL, you'll need a master clock that is higher than your
target frequency. Typically, you'll need something that is at least 16x,
which puts the design frequency near the upper limit of what you'll be
able to do in the device. The higher your master, the smaller the
resulting jitter. You could put a ring oscillator in your design to
generate a high frequency master. The ring oscillator's frequency would
be sensitive to temperature, supply voltage and possibly the phase of the
moon, but since you would be using for a reference in a DPLL, the drift
would probably be OK as long as it wasn't fast compared to your output
frequency. The other option would be to implement a delay lock loop,
although I think the delay granularity possible in the CPLD may make that
impractical.
Colin Bury wrote:
> Hi,
>
> I need to multiply a clock from around 44kHz to 11MHz, to be
> implemented in a Lattice ISP (Programmable Logic) device.
>
> Does anyone know of how to implement a clock multiplier in
> VHDL/Verilog or have any schematics or references?
> I am considering trying to implement an All-Digital PLL (due to noise
> considerations I would prefer not use an analogue VCO), does anyone
> have any idea/know of any references on how to do this?
> Am I being stupid, or is it possible to implement this without using a
> high frequency external reference clock?
>
> Any help would be greatly appreciated.
>
> Colin Bury
> eeburyc@swan.ac.uk
> University of Wales Swansea
--
--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: 40182I am not using a PLL outside (I don't think - would the DAC have one?). At the moment my clock configuration is as follows: clk33 comes in on a pin and is fed through a DLL to the design. clk425 also comes in on a pin and is fed through a DLL to the design. I then use Phil's code to create the en425 signal which I use to enable my process C which needs to run at 425kHz to feed the DAC. Do you mean use a DLL on the FPGA to route my DAC clock out? The DAC did work perfectly before when I got my design to work without doing Phils clock synchronisation. I just fed the clk425 out to the DAC on the correct pin. Now I am just not sure how to clock my DAC - do I feed en425 into a DLL and then out to the DAC? Thanks for your help, Ken. > Hi Ken, > > Are you using any PLLs outside? If yes, then if you do an environment > testing with the "Phil" modified code, you may see that for a > particular temperature your design works perfectly. > > Use a DLL in the FPGA instead.This is just a solution on hunch. > Have a good day. > SANKET.Article: 40183
Pipelining ? For more than result though. Rene Prashant wrote: > hi, > > Do the different devices in the APEX20KE family have different maximum > speeds of operation. e.g. Would EP20K1500E be expected to run much > faster than EP20K160E ? > > I'm trying to implement a 16x16 combinational multiplier in the > EP20K160E. But the timing simulations seem to take 40-50 ns for a > single multiply. > > Anyone have any ideas, how can I speedup the operation.Article: 40184
> 1) You can invert it with one pass through your part then bring it back Going outside of device and entering with inverted signal into other pin? OK > in and make your tools happy. And what means that message 'signal usage may not be global' or sth like that is generated? Are there any disadvantages other than some delays in clock propagation? Can I safely ignore this message? (Part runs OK with this message) or there are 'hidden' things happenig when such message is generated? jerryArticle: 40185
In my project I use a Asynchronous FIFO CORE version 4 to synchronize
the data clock coming from the pattern generator with the internal
clock (..having about the same frequency) produced by my circuit. This
clock arrive to the FIFO CORE via a BUFG according to an answer
database Xilinx message that tells to do exactly this to achieve that
the signal could use a global clock line.
The result is that after Place & Route I have the warning
-----------------------
WARNING:Timing - Clock nets using non-dedicated resources were found
in this
design. Clock skew on these resources will not be automatically
addressed
during path analysis. To create a timing report that analyzes clock
skew for
these paths, run trce with the '-skew' option.
The following clock nets use non-dedicated resources:
clk_to_fifo
--------------------------
where clk_to_fifo is between bufg and the wr_clk of the FIFO, I also
try to assign to this signal the attribute USEGLOBALCLOCKLINES via the
constain Editor of XST but the result at the end of P&R is always
this.
How can I take it away ??
Antonio
Article: 40186Thomas, The DCM has a divide by 2 prescaler in it. I use FPGA Editor to use it, so I am not sure how it is done in verilog/vhdl, or if it is in the schematic primitive as an attribute (I guess you could call be a hopeless bit hacker, but then, that is what we do in the Lab to test everything). The prescaler has been tested to beyond the frequency to mention....way beyond. The difficulty is in getting the signal inside. LVPECL/LVDS input buffer will work at 622 MHz, but you must be extra careful with your signal integrity at this frequency, and carefully model the termination and the traces to the package, taking into account the short t-lines in the package itself (see the comments at the beginning of the IBIS files). Once inside and divided by two, the DCM can lock on it, and if no DCM jitter is allowed (I'm guessing this is SONET/SDH), the DCM can be placed in "Freeze" mode by tying the LOCKED pin to the Freeze_DLL pin. This will stop all DCM tap processing, and will leave you with the deskewed, and duty cycle corrected taps that were chosen, so later with changes to voltage and temperature the skew and duty cycle will vary by some small amount. The DCM is temperature compensated, so temperature alone results in a +/- 5% error, roughly. The you can use the DIV=4 attribute and CLKDV output to a BUFG to a DDR FF to forward a 155 MHz clock. To remove jitter, and make the clock SONET/SDH compliant, an ICS 8745 PLL (or 8735 for LVPECL) can be used to remove (almost) all of the jitter added by switching IOs, ground bounce, etc. Completely integrated (no external RCs for the PLL): http://www.icst.com/pdf/ics8735-01.pdf Tests in the FPGA Lab show less than 40 ps P-P total jitter with an input that has as much as 500 ps P-P from the FPGA (jitter added to test the effectiveness of the PLL). ICS has designed their PLL to have its pole and filter response such that it compements the Virtex DLL and DCM tap update rates for best attentuation. As with any PLL, it has its own quiet power supply pins so that it can actually attentuate the jitter. Austin Thomas Zipper wrote: > Hi, > there were some "counter discussions" in this newsgroup, however I wonder if > it might be possible to > > - divide down a couple of LVPECL clocks running at 622 MHz to a few MHz or > kHz and > > - build a programmable LVPECL divider that can either pass 155 MHz and drive > it off-chip as LVDS clock or divide down a 622 MHz LVPECL clock to 155 MHz > and again drive it as LVDS clock to an another chip on board > > I requirement would be, that the FPGA is small in respect to the board > space - the small Virtex-II 50/80 (BGA256) devices looking very nice. > > Might there be a way to do that? > > Bye > > ThomasArticle: 40187
Thomas,
Based on what I recall of the speed ratings of the Virtex2 I would be
skeptical. However, I seem to recall Peter Alfke mentioning that he was working
on a 1 gig frequency counter in the Virtex2 chip. Given that Peter tends to
produce what he plans on, I would guess that your 622 MHz _might_ be
attainable. In particular, if you can keep the temperature down and make
certain that the core supply voltage is on the high side. I just looked and the
Virtex2 does list an internal toggle frequency that high. BTW, can anyone tell
me what the "For export control" statement means? Is that a US governmental
thing or is that "real"?
As an alternative, could you get away with a simple divide by 2 low voltage ECL
chip. I know that Onsemi has one in the 8 pin tssop package. It will run at as
low as 3 volts. For example the MC100EP32DT is a divide by 2 or the MC100EP33DT
is a divide by 4. They also have an mc100lvep34 in a tssop16 that runs on 2.5
volts. It is a divideby 2,4,and 8.
Good luck,
Theron
Thomas Zipper wrote:
> Hi,
> there were some "counter discussions" in this newsgroup, however I wonder if
> it might be possible to
>
> - divide down a couple of LVPECL clocks running at 622 MHz to a few MHz or
> kHz and
>
> - build a programmable LVPECL divider that can either pass 155 MHz and drive
> it off-chip as LVDS clock or divide down a 622 MHz LVPECL clock to 155 MHz
> and again drive it as LVDS clock to an another chip on board
>
> I requirement would be, that the FPGA is small in respect to the board
> space - the small Virtex-II 50/80 (BGA256) devices looking very nice.
>
> Might there be a way to do that?
>
> Bye
>
> Thomas
Article: 40188Terry, No probelm, see my post. Works over the temp range just fine. The 1/2 presscaler is the trick Peter is using for the counter. Austin "Theron Hicks (Terry)" wrote: > Thomas, > Based on what I recall of the speed ratings of the Virtex2 I would be > skeptical. However, I seem to recall Peter Alfke mentioning that he was working > on a 1 gig frequency counter in the Virtex2 chip. Given that Peter tends to > produce what he plans on, I would guess that your 622 MHz _might_ be > attainable. In particular, if you can keep the temperature down and make > certain that the core supply voltage is on the high side. I just looked and the > Virtex2 does list an internal toggle frequency that high. BTW, can anyone tell > me what the "For export control" statement means? Is that a US governmental > thing or is that "real"? > > As an alternative, could you get away with a simple divide by 2 low voltage ECL > chip. I know that Onsemi has one in the 8 pin tssop package. It will run at as > low as 3 volts. For example the MC100EP32DT is a divide by 2 or the MC100EP33DT > is a divide by 4. They also have an mc100lvep34 in a tssop16 that runs on 2.5 > volts. It is a divideby 2,4,and 8. > > Good luck, > Theron > > Thomas Zipper wrote: > > > Hi, > > there were some "counter discussions" in this newsgroup, however I wonder if > > it might be possible to > > > > - divide down a couple of LVPECL clocks running at 622 MHz to a few MHz or > > kHz and > > > > - build a programmable LVPECL divider that can either pass 155 MHz and drive > > it off-chip as LVDS clock or divide down a 622 MHz LVPECL clock to 155 MHz > > and again drive it as LVDS clock to an another chip on board > > > > I requirement would be, that the FPGA is small in respect to the board > > space - the small Virtex-II 50/80 (BGA256) devices looking very nice. > > > > Might there be a way to do that? > > > > Bye > > > > ThomasArticle: 40189
Hello Johnny, This feature is not yet available in ISE software. To use a netlist in an HDL flow, you could create a wrapper HDL file where the netlist is instantiated, and then create a schematic symbol from that source. I hope this helps.Article: 40190
My thoughts are that you'll need a high(er) frequency external clock of some kind. What are your jitter requirements on the 11MHz? If you just need an average of 11MHz and you can skip an entire clock cycle (90ns jitter), a digital PLL can be designed pretty easily. If you can get by with a few ns of jitter, there are techniques that can still produce good results without going to extremes, but that's in brand X devices. You'll most probably end up with a tradeoff of jitter versus external frequency to deal with. Think of a digital PLL as an arithmetic equivalent of an analog PLL and you may see how to design the DPLL with limited logic requirements (phase comparator provides an error in counts of the high frequency reference, the CRC 2nd order filter can be approximated with some shift and accumulation, the VCO is realized as a phase accumulator based off the high speed clock). The Xilinx Virtex-II devices have some nice internal digital clock management units that can provide high speed clocks (based on at least 25MHz input frequency) with variable phase values and "global clock mux" elements that allow glitchless switching between phases to end up with a *very* resolute clock (in digital terms) without breaking the bank in the smallest device of the family. But Lattice? Dunno. - John_H Colin Bury wrote: > Hi, > > I need to multiply a clock from around 44kHz to 11MHz, to be > implemented in a Lattice ISP (Programmable Logic) device. > > Does anyone know of how to implement a clock multiplier in > VHDL/Verilog or have any schematics or references? > I am considering trying to implement an All-Digital PLL (due to noise > considerations I would prefer not use an analogue VCO), does anyone > have any idea/know of any references on how to do this? > Am I being stupid, or is it possible to implement this without using a > high frequency external reference clock? > > Any help would be greatly appreciated. > > Colin Bury > eeburyc@swan.ac.uk > University of Wales SwanseaArticle: 40191
Are there many good FPGA design firms in Alaska? I understand they've got a bunch of people familiar with pipelining up there. Nicholas Weaver wrote: > B) Pipeline. Pipeline. With FPGAs, ALWAYS pipeline!Article: 40192
Thank you for the insight. We're still evaluating both solutions and are eager to compare things without any of the marketing discussion you refer to. My coworker can't wait for the GUI. My comments on the use of m-blaze refer to version "2.1" which we downloaded after getting registered. Perhaps you can help me understand a technical detail of the m-blaze memory architecture & associated compiler options: Your MDK Tutorial doc, page 1-9, describes the use of "-mxl-gp-opt". The description implies we can use this option to speed on-chip memory access for address spaces addressable by the 16 bit Immediate. My confusion comes from bit 9 of the address space, which is used to define whether the peripheral is on the LMB or OPB. So, what is the maximum size of on-chip memory that can be used with this compiler option? 2^15 or 2^8 or 2^? Regards, Jesse Kempa Goran Bilski <goran@xilinx.com> wrote in message news:<3C7E916F.AABFA453@xilinx.com>... > Hi, > > In order to get that system working you could only copy one of the predef > ined example > and change a few lines, not several pages. > I'm not sure if I want to into all the difference between MicroBlaze and > NIOS without > maybe stepping into marketing territory. > And I'm sure that you didn't try the latest MDK 2.1 of MicroBlaze, that i > s a much improved > version > over the 1.9 > > The normal distribution of MDK is over the internet. > > Xilinx will some also come out with some GUI driven system generation as > well. > > > G?an Bilski > > > Jesse Kempa wrote: > > > I can help elaborate on this one. I've seen both kits, and have been > > won over by Nios myself. > > > > A coworker of mine ordered his MicroBlaze kit last year and it took > > over two months to show up. While I found that the Insight development > > board was a pretty good softcore CPU development platform (as is the > > Nios dev board), the MicroBlaze product itself is a bit (to say the > > least) lacking. After receiving the kit and opening it up we found no > > MicroBlaze CD! It showed up in a separate mailing on a generic CD-R, > > as if it were burned on some engineer's cubicle CD burner. > > > > These tidbits aside, the MicroBlaze design flow is entirely script > > based - without any GUI. Nios is also script based, but it is all > > abstracted in their system builder software. In order to get a basic > > m-blaze system with CPU and a couple peripherals (UART, general > > purpose IO), a couple of pages of typing are required to instantiate > > everything! One goof up and no system for you! The Nios kit GUI lets > > you make an equivalent system in seconds. > > > > -- Jesse Kempa > > > > emanuel stiebler <emu@ecubics.com> wrote in message news:<3C7D300C.3B55 > 34A1@ecubics.com>... > > > Victor Schutte wrote: > > > > > > > > I have given up trying to get hold of it. > > > > > > Care to elaborate a little further ? > > > > > > > I am now hooked on NIOS ver 2.0. > > > > Excellent IP. > > > > > > I'll check ;-) > > > > > > cheers & thanksArticle: 40193
Jesse Kempa wrote: > > Thank you for the insight. We're still evaluating both solutions and > are eager to compare things without any of the marketing discussion > you refer to. That's what I was asking for. An opinion of the usability of the microblaze. Can't go to altera ... > My coworker can't wait for the GUI. The GUI is probably the last thing I'm waiting for. Better documentation, more examples how to use it, more peripherals, OPB SDRAM, ... > My comments on the use of m-blaze refer to version "2.1" which we > downloaded after getting registered. So, it is really available ? Did you get the source with it ? Cheers, emanuelArticle: 40194
Does anyone have a nice hi-res photo of a Xilinx Virtex CLB or general die? Google has failed me. thanks. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 40195
Hi, The bit 9 for determine LMB or OPB accesses is just temporal it will vani= shed in future releases when the tools automatically figure out the address decoding between LMB and O= PB. The compiler doesn't know if an address is in LMB or OPB, is just address= es for the compiler. Use of -mxl-gp-opt option: -mxl-gp-opt option will only access data of size 8 bytes and less using t= he special small data anchors [r13 an r2] . For all other memory accesses, absolute value will be used. for e.g. .. if you have gl= obal variables: int a, b, c, x[100]; Variables a, b and c will be put in small data area, which is accessed us= ing the small data anchor [r13]. but the array x will be put in the data area and will be accessed using the absolute memory location = address. Thus -mxl-gp-opt will be of no use for such array accesses. You can read about this in: "MicroBlaze Platform Generator" section of swref.pdf and (even more impor= tant) the "MicroBlaze Address Map" section of the swref.pdf doc. Hope that this helps G=F6ran Bilski Jesse Kempa wrote: > Thank you for the insight. We're still evaluating both solutions and > are eager to compare things without any of the marketing discussion > you refer to. My coworker can't wait for the GUI. > > My comments on the use of m-blaze refer to version "2.1" which we > downloaded after getting registered. > > Perhaps you can help me understand a technical detail of the m-blaze > memory architecture & associated compiler options: > > Your MDK Tutorial doc, page 1-9, describes the use of "-mxl-gp-opt". > The description implies we can use this option to speed on-chip memory > access for address spaces addressable by the 16 bit Immediate. > > My confusion comes from bit 9 of the address space, which is used to > define whether the peripheral is on the LMB or OPB. So, what is the > maximum size of on-chip memory that can be used with this compiler > option? 2^15 or 2^8 or 2^? > > Regards, > > Jesse Kempa > > Goran Bilski <goran@xilinx.com> wrote in message news:<3C7E916F.AABFA45= 3@xilinx.com>... > > Hi, > > > > In order to get that system working you could only copy one of the pr= edef > > ined example > > and change a few lines, not several pages. > > I'm not sure if I want to into all the difference between MicroBlaze = and > > NIOS without > > maybe stepping into marketing territory. > > And I'm sure that you didn't try the latest MDK 2.1 of MicroBlaze, th= at i > > s a much improved > > version > > over the 1.9 > > > > The normal distribution of MDK is over the internet. > > > > Xilinx will some also come out with some GUI driven system generation= as > > well. > > > > > > G?an Bilski > > > > > > Jesse Kempa wrote: > > > > > I can help elaborate on this one. I've seen both kits, and have bee= n > > > won over by Nios myself. > > > > > > A coworker of mine ordered his MicroBlaze kit last year and it took= > > > over two months to show up. While I found that the Insight developm= ent > > > board was a pretty good softcore CPU development platform (as is th= e > > > Nios dev board), the MicroBlaze product itself is a bit (to say the= > > > least) lacking. After receiving the kit and opening it up we found = no > > > MicroBlaze CD! It showed up in a separate mailing on a generic CD-R= , > > > as if it were burned on some engineer's cubicle CD burner. > > > > > > These tidbits aside, the MicroBlaze design flow is entirely script > > > based - without any GUI. Nios is also script based, but it is all > > > abstracted in their system builder software. In order to get a bas= ic > > > m-blaze system with CPU and a couple peripherals (UART, general > > > purpose IO), a couple of pages of typing are required to instantiat= e > > > everything! One goof up and no system for you! The Nios kit GUI let= s > > > you make an equivalent system in seconds. > > > > > > -- Jesse Kempa > > > > > > emanuel stiebler <emu@ecubics.com> wrote in message news:<3C7D300C.= 3B55 > > 34A1@ecubics.com>... > > > > Victor Schutte wrote: > > > > > > > > > > I have given up trying to get hold of it. > > > > > > > > Care to elaborate a little further ? > > > > > > > > > I am now hooked on NIOS ver 2.0. > > > > > Excellent IP. > > > > > > > > I'll check ;-) > > > > > > > > cheers & thanksArticle: 40196
I would continue to use the 425 kHz clock to clock the DAC. I would
then use the rising edge of this clock to latch the data out to the DAC
data pins. I belive the 425enable signal can just tell the 33 MHz
Process B to load new data into the previous register.
But I actually would have done your processes a little differently. One
of the nice things about the memory in a Spartan II is that they are
dual ported with independent clocks. Unless you need a control signal
(like Empty or Full) passing between the two domains, you could easily
move data without the messy metastability issues.
Actually, you HAVE to have some controls passing between the two clock
domains because there has to be a counter that increments when you put
data in and decrements when you take data out. But this is very easy
and is essentially like the syncing you did on the 425EN signal. But it
would eliminate the Process B logic. The wide difference in clock
speeds makes this a much simpler problem. I assume that you are writing
blocks of data to the FIFO? If you are responding to each word that is
read out to the DAC, then you don't need the FIFO, right?
Ken Mac wrote:
>
> Phil,
>
> Forgot to mention that the DAC is fed the 425kHz clock via a pin of my
> Spartan-II.
>
> The DAC uses the negative edges of the 425kHz clock to take data from
> process C.
>
> Process C uses the positive edges of the 425kHz clock to place data on the
> serial data pin for the DAC and the negative edges then drive the DAC.
>
> My DAC output now seems to be irregular - what signal should I use to clock
> my DAC now?
>
> Thanks again,
>
> Ken
>
> > > Process A: Runs at 33MHz to fill a 16 location FIFO with 8-bit data
> > > samples and then keep it full.
> > > Process B: Runs at 33MHz to take data from the FIFO when told to and
> > > supply it to process C via a register.
> > > Process C: Runs at 425kHz and sends FIFO 8-bit data samples to a DAC
> > > bit-serially then asks process B for next piece of data.
> >
> > > Process A is fed with data via a Visual C++ app (the Spartan-II is
> mounted
> > > on a PCI board) which is synchronised with the FPGA using an interrupt
> pin
> > > that the FPGA can assert and the C++ can read.
> > >
> > > I have used this system for many designs with no trouble (none of them
> had
> > > multiple clock domains however). The problem here is that the design is
> > > getting stuck in state for no apparent reason! (i.e. the C++ hangs
> waiting
> > > for the interrupt pin!).
> >
> > Sounds to me like you have a problem crossing clock domains.
> >
> >
> > > The system works for a random number of samples (between 28 and 33 it
> seems)
> > > and then gets stuck in state. This is very strange because it means that
> my
> > > protocols do work.
> >
> > Not strange at all. Suppose we have two registers in one clock domain
> sampling
> > a signal from the other clock domain. If both get the same value for the
> next
> > clock, the logic works. If only one gets the value, the logic hangs.
> >
> >
> > > The weird thing is that I put a piece of debug code in another state to
> send
> > > a signal out to a pin to probe, I ran the flow again to get a bitstream
> and
> > > the system ran perfectly for all 75001 samples I am using! The debug
> code
> > > was "Debug <= '1'".
> >
> > Different placement, different routing, different timing, different odds
> of
> > failure. Might work well at 25C, and fail like above at 28C.
> >
> > > Then I enabled clock DLLs using the BUFGDLL component and it hangs
> again!
> >
> > Different timing, different odds of failure.
> >
> >
> > > Previously, I had it working perfectly using the clock DLLs but without
> a
> > > FIFO (i.e. 1 sample at a time from C++ to FPGA to DAC) but I got some
> > > stutters hence I introduced the FIFO.
> > >
> > > In that design I also had hanging problems but after I rejigged my
> protocol
> > > in my VHDL state machines it worked perfectly.
> > >
> > > It seems that seemingly random changes of VHDL make or break the system.
> I
> > > guess it must be to do with my 2 different clock rates but that is the
> way
> > > it has to be.
> > >
> > > I am at a loss - anyone any ideas?
> >
> > First, sync the 425KHz to 33 MHz, then edge detect, and then use the edge
> > detected clock 425 for a clock enable for process C. Code fragments:
> >
> > process(clk33) begin
> > if rising_edge(clk33) then
> > synslow <= clk425;
> > synslow2 <= synslow;
> > synslow3 <= synslow2;
> > en425 <= synslow2 and not synslow3;
> > end if;
> > end process;
> >
> > processc:
> > process(clk33) begin -- was (clk425)
> > if rising_edge(clk33)
> > if en425 = '1' then -- was rising_edge(clk425)
> > ....
> >
> > The reason this (hopefully!) will solve your problem is that almost all
> logic
> > will be running on a single clock. While there is a chance that synslow
> will
> > not correctly clock in clk425 on rising or falling edge ("go metastable"),
> > synslow2 is much less likely to fail (As mean time between failures >> age
> of
> > universe), and en425 even less so.
> >
> > Also, you could synchronize all control signals between the two processes.
> More
> > complex.
> >
> >
> > --
> > Phil Hays
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Article: 40197Hello, I want to buy Altera's softcore uP. Which one: Nios-based or Arm-based? Any suggestions? Before spending money for development tools I'd like to know the good and bad news for it. Is it possible to move from Nios to Arm-based without spending lot of money for Arm option (already having Nios purchased)? Thanks jerryArticle: 40198
you are the second to mention the Xilinx DLLs/DCMs. Unfortunately, they are
of no use here since the input clock is only 44 KHz, and even the desired
output is less than half the minimum frequency for those blocks. As for the
DPLL, it is not really a direct port from an analog PLL, there are usually no
filters per se. Instead, the 'filtering' is done by the counters. Actel has
an app note on doing DPLLs in FPGAs that is fairly decent. see
http://www.actel.com/appnotes/s04_18.pdf. You might also look at some of the
old DPLL device data sheets. You'll still need some source of clock that is
faster than your intended output. As I mentioned earlier, if adding an extra
external clock is unacceptable, you may be able to use a ring oscillator in
the design.
John_H wrote:
> My thoughts are that you'll need a high(er) frequency external clock of
> some kind. What are your jitter requirements on the 11MHz? If you just
> need an average of 11MHz and you can skip an entire clock cycle (90ns
> jitter), a digital PLL can be designed pretty easily. If you can get by
> with a few ns of jitter, there are techniques that can still produce good
> results without going to extremes, but that's in brand X devices.
>
> You'll most probably end up with a tradeoff of jitter versus external
> frequency to deal with.
>
> Think of a digital PLL as an arithmetic equivalent of an analog PLL and
> you may see how to design the DPLL with limited logic requirements (phase
> comparator provides an error in counts of the high frequency reference,
> the CRC 2nd order filter can be approximated with some shift and
> accumulation, the VCO is realized as a phase accumulator based off the
> high speed clock).
>
> The Xilinx Virtex-II devices have some nice internal digital clock
> management units that can provide high speed clocks (based on at least
> 25MHz input frequency) with variable phase values and "global clock mux"
> elements that allow glitchless switching between phases to end up with a
> *very* resolute clock (in digital terms) without breaking the bank in the
> smallest device of the family.
>
> But Lattice? Dunno.
>
> - John_H
>
> Colin Bury wrote:
>
> > Hi,
> >
> > I need to multiply a clock from around 44kHz to 11MHz, to be
> > implemented in a Lattice ISP (Programmable Logic) device.
> >
> > Does anyone know of how to implement a clock multiplier in
> > VHDL/Verilog or have any schematics or references?
> > I am considering trying to implement an All-Digital PLL (due to noise
> > considerations I would prefer not use an analogue VCO), does anyone
> > have any idea/know of any references on how to do this?
> > Am I being stupid, or is it possible to implement this without using a
> > high frequency external reference clock?
> >
> > Any help would be greatly appreciated.
> >
> > Colin Bury
> > eeburyc@swan.ac.uk
> > University of Wales Swansea
--
--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: 40199
VirtexE BRAMs can be written at 155MHz in any speed grade. To do so, you will
likely have to put registers near to and with no logic between them and the
BRAMs. Watch the loading too, routing to more than 1 BRAM for each register may
cause you some heartburn. At higher speeds, you probably should also consider
tying the WE, and ENA inputs active and controlling your access through the
address registers instead. You'll also need to floorplan the registers to make
sure they are located physically close to the BRAMs.
"H.L" wrote:
> Hi Peter, thanks for your reply
> I was confident of this method's effectiveness but now I am worried :)) . I
> have already done a timing analysis in the paper and also the simulation
> waveforms seem promising.
> I didnt understand what do you mean when telling me that one of my words
> arrives early and the other one late. The transmitter sends to my FPGA an
> external clock (thats the 155MHz clock), a valid signal (1 bit indicating
> the transmission time period) and of course the 16-bit words that I have to
> store. Every clock period (~6 ns) I have available in my ports one 16-bit
> word, I register two sequential words from the in port to a 32-bit register
> (31->16 the first incoming word, 15->0 the second one). Then , in another
> 32-bit register I register (2 nd time) the 32-bit word I just "made" which
> are the BRAM data_in. All the above operations are in a process that has in
> its sensitivity list the 155 clock. I write to the BRAM at 77MHz using the
> incoming clock divide by 2 using a DLL. BRAM input signals are assigned in
> the falling edge of the 77MHz clock so as to be before the rising edge (of
> the same clock) where the BRAM samples them. The write operations are in
> another process with the slow clock in its sensitivity list.
> The timing waveforms of the simulation are the same with the timing analysis
> in paper but does this is a valid hardware design technique?
> Thanks for your time and help!
>
> Best Regards,
> Harris
>
> p.s: thats a small part of my design. I use DLL because other parts need
> them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155 MHz and I
> got many timing errors (floorplanning managed to reduce them but still lot
> of work to be done)
>
> "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> news:3C7E621F.1E77A244@xilinx.com...
> > I suggest you grab pencil and paper and do a clock-by-clock timing
> analysis. You
> > will find that your clock-speed reduction buys you nothing, unless you
> also
> > double-buffer the data.
> > One of your words arrives nice and early, the other one late. However you
> clock
> > the BRAM, one of the two words has the same old short set-up time...
> > Double-buffering would help. But Ray has mentioned some neat tricks to
> avoid the
> > long set-up time of the control inputs.
> >
> > I will get back with more constructive notes. "Gotta run"
> >
> > Peter Alfke
> > ===================
> > "H.L" wrote:
> >
> > > Hello all,
> > >
> > > I have a module that accepts 16 bit words at 155MHz and I want to store
> then
> > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA) to
> divide by
> > > 2 the 155MHz clock as this frequency seems to be pretty high to write in
> the
> > > BRAM. So far I think 2 processes are enough to do my job, one operating
> @
> > > 155MHz to accept the 16-bit data and store them in a 32-bit register and
> the
> > > another one @ 75MHz to write the content of the 32-bit register in the
> BRAM.
> > > I am thinking to assign the BRAM's signals
> (ENABLE,WRITE,ADDRESS,DATA_IN) in
> > > the falling edge of the 75MHz clock, the main reason for this is the
> setup
> > > time of the BRAMs signals (in this way the address,data are 6 ns before
> next
> > > rising edge of the clock where BRAM samples its inputs). My question now
> :)
> > > , if one process uses the falling edge of one clock does this causes
> > > problems to other processes in the design , e.g to processes that use a
> > > different clock or to processes using the rising edge of the same
> clock?
> > >
> > > Best Regards,
> > > Harris.
> >
--
--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
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