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
Try Altera App Note 311: ASIC to FPGA design methodology and guidelines. http://www.altera.com/literature/an/an311.pdf Hope this helps, Subroto Datta Altera Corp. "srini" <g.shrinivasan@gmail.com> wrote in message news:1152025016.706664.181450@m79g2000cwm.googlegroups.com... > Hello experts, > Would like to hear from you regarding the precautions, the common > practices and problems that arise when migrating an ASIC RTL code into > an FPGA. > > Thanks & Regards, > Srini. >Article: 104701
And second item shown up by a google search for asic fpga methodology :-) Subroto Datta wrote: > Try Altera App Note 311: ASIC to FPGA design methodology and guidelines. > http://www.altera.com/literature/an/an311.pdf > > Hope this helps, > Subroto Datta > Altera Corp. > > "srini" <g.shrinivasan@gmail.com> wrote in message > news:1152025016.706664.181450@m79g2000cwm.googlegroups.com... > >>Hello experts, >>Would like to hear from you regarding the precautions, the common >>practices and problems that arise when migrating an ASIC RTL code into >>an FPGA. >> >>Thanks & Regards, >>Srini. >> >> > >Article: 104702
Hello all, I would like to learn if there is an open source for an adpll. I need to lock a 2kHz sync signal to 50Hz main. Many thanks in advance. Rasit.Article: 104703
raso schrieb: > Hello all, > > I would like to learn if there is an open source for > an adpll. > I need to lock a 2kHz sync signal to 50Hz main. I have a VHDL description of the 74xx297. I you like to get the code, drop me a mail. Regards FalkArticle: 104704
Peter Alfke wrote: > I am so happy to have removed the mystery from metastability. I do not > want to get chaos back in. > It is the simplicity of the CMOS latch structure that causes > metastability to be so well-behaved and incapable of any oscillation. > Nobody has ever reported oscillation in CMOS latches (but well in TTL > structures that are more complex). Hurray for simplicity... > I think the pen analogy is valid... What feature about the CMOS latch makes it impossible to oscillate? My understanding is that there are two nodes with logic driving them to opposite polarities. If the FF is driven into metastability the two nodes can be driven to the same state which due to the logic, is unstable. since there is a delay from the input to the output of each node, it should be possible for each node to drive the other to the opposite state, then both nodes will be in the other state and drive the other node to the original state, etc. What prevents this in CMOS logic?Article: 104705
"rickman" <spamgoeshere4@yahoo.com> wrote: >What feature about the CMOS latch makes it impossible to oscillate? My >understanding is that there are two nodes with logic driving them to >opposite polarities. If the FF is driven into metastability the two >nodes can be driven to the same state which due to the logic, is >unstable. since there is a delay from the input to the output of each >node, it should be possible for each node to drive the other to the >opposite state, then both nodes will be in the other state and drive >the other node to the original state, etc. What prevents this in CMOS >logic? Disclaimer: naive understanding exposed herein, without benefit of clear understanding of control theory :-) Roughly, I think it's because the CMOS latch circuit has only 2 gain stages in its loop, and both of them have delays that are dominated by an RC effect (first-order) and, by comparison, its time delays are negligible. So the whole thing is quite highly damped. By contrast, TTL latch circuits often had rather more gain stages, I think. If you simply cross-couple a pair of bipolar transistors you get an embarrassingly slow circuit; TTL used all kinds of tricks to make it faster - remember that NPN transistors were cheap, but just about any other kind of component on TTL was troublesome to make. If you use an ordinary digital simulator to model a two-inverter feedback loop, and give each inverter a pure time delay, it's easy to make the thing oscillate by prodding it appropriately. But if the two inverting gain stages have a first-order RC-type lag that swamps their propagation delay, an analog simulation will show the thing settling monotonically after any disturbance from its metastable "balance point". I'd be *very* pleased to hear any experts explaining, in a way that I can understand both mathematically and intuitively, a more rigorous version. Control theory always pushed the limits of my mathematical competence, and as the math wiring in my head shows an approximately exponential decay with time, it needs to be pretty simple these days if I'm going to follow it... -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 104706
Thanks Mark for answering that - been (and still am) on holiday :) /Mike "Mark McDougall" <markm@vl.com.au> wrote in message news:44a4b398$0$12251$5a62ac22@per-qv1-newsreader-01.iinet.net.au... > deunhido@gmail.com wrote: > > > Would it also be possible to use a solution as in XAPP154, "Virtex > > Synthesizable Delta-Sigma DAC"? > > No, the frequency of the video output is *way* too high for such a DAC. > e.g. For normal VGA output, you'd need to run the DAC at about 6.4GHz > for 24-bit RGB. > > Regards, > > -- > Mark McDougall, Engineer > Virtual Logic Pty Ltd, <http://www.vl.com.au> > 21-25 King St, Rockdale, 2216 > Ph: +612-9599-3255 Fax: +612-9599-3266Article: 104707
On 3 Jul 2006 23:22:15 -0700, "Peter Alfke" <alfke@sbcglobal.net> wrote: >I am so happy to have removed the mystery from metastability. I do not >want to get chaos back in. >It is the simplicity of the CMOS latch structure that causes >metastability to be so well-behaved and incapable of any oscillation. >Nobody has ever reported oscillation in CMOS latches (but well in TTL >structures that are more complex). Hurray for simplicity... >I think the pen analogy is valid... TTL flipflops were symmetric master-slave architectures with lots of delay in the positive feedback path. If they did get into serious oscillation, the saturation of various stages effectively reduced positive-feedback loop gain. LSTTL was notorious for metastable oscillations, with hundreds of cycles, lasting microseconds, observed. An FM radio would now and then click when placed near a big LSTTL system. CMOS transmission-gate latches don't have this combination of symmetry and delay, so don't oscillate; the balanced pen is a good analogy. I've seen ecl flops ring once before resolving, but I don't think they sustain an oscillation either. JohnArticle: 104708
I am trying to constrain a single path through my V4 fpga in ISE 6.3. In the VHDL source it simply connects an input pin to an output pin: SER_Clock <= Sclk_in_dec; In the .ucf I then try to constrain with: NET "Sclk_in_dec" TNM_NET = "Sclk_in_dec"; NET "Ser_Clock" TNM_NET = "Ser_Clock"; TIMESPEC "TS_P2P" = FROM "Sclk_in_dec" TO "Ser_Clock" 5 ns; But the constraint ends up being ignored:Article: 104709
Oops, accidently sent, see below: "Anonymous" <someone@microsoft.com> wrote in message news:JuCqg.12132$so3.9108@southeast.rr.com... > I am trying to constrain a single path through my V4 fpga in ISE 6.3. In the > VHDL source it simply connects an input pin to an output pin: > > SER_Clock <= Sclk_in_dec; > > In the .ucf I then try to constrain with: > > NET "Sclk_in_dec" TNM_NET = "Sclk_in_dec"; > NET "Ser_Clock" TNM_NET = "Ser_Clock"; > TIMESPEC "TS_P2P" = FROM "Sclk_in_dec" TO "Ser_Clock" 5 ns; > > But the constraint ends up being ignored: > > WARNING:Timing:2666 - Constraint ignored: TS_P2P = MAXDELAY FROM TIMEGRP "Sclk_in_dec" TO TIMEGRP "Ser_Clock" 5 nS ; Anyone know how to do this properly for a signle path? I've tried the "from PADS to PADS" global constraint but it is too restrictive for what I need. Thanks, ClarkArticle: 104710
>I think the pen analogy is valid... I use a ball rolling over a speed-bump. It's naturally only one dimensional. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 104711
hi, Vivek I had the same issue on the UART core. Can you point me the link and solution to download it? Thanks Frank Vivek Menon wrote: > Matter resolved. > Ken pointed me to the latest UART core being shipped with the Picoblaze > module for Virtex-II Pro designs. I had some trouble downloading the > picoblaze module, but thanks to Ed, the UART core is working > successfully on my board. > Thanks once again, > Vivek > > > Ray Andraka wrote: > > Aurelian Lazarut wrote: > > > > > run map with -ir (ignore RLOCs) > > > or if you use ISE, change map propreties by unchecking "use RLOC...." > > > Aurash > > > > > > > I don't believe that will work. I think the RLOCs are still parsed with > > that switch set, in which case it will error out with the same complaint.Article: 104712
Hi Antti, Antti wrote: > MicroBlaze 4.0 has still to > my knowledge issues with uClinux, details? I'm not aware of any issues, and there's no chatter about such on the mb-uclinux list. JohnArticle: 104713
Anonymous wrote: > > In the .ucf I then try to constrain with: > > NET "Sclk_in_dec" TNM_NET = "Sclk_in_dec"; > > NET "Ser_Clock" TNM_NET = "Ser_Clock"; > > TIMESPEC "TS_P2P" = FROM "Sclk_in_dec" TO "Ser_Clock" 5 ns; > > > > But the constraint ends up being ignored: > WARNING:Timing:2666 - Constraint ignored: TS_P2P = MAXDELAY FROM TIMEGRP > "Sclk_in_dec" TO TIMEGRP "Ser_Clock" 5 nS ; > Anyone know how to do this properly for a signle path? Form your two timegroups using the instance names for the two iobs: INST "a" TNM = "In_Pad"; INST "b" TNM = "Out_Pad"; This can be done under the advanced tab of the constraints editor. Use whatever instance names your pads wind up with, instead of the "a" and "b" I show here. Then your FROM-TO timespec will work: TIMESPEC "TS_A2B" = FROM "In_Pad" TO "Out_Pad" 7 ns; Note that the TNM_NET grouping constraint fans (traces) forward, not backwards, and will not include the pad that sources the net, and thus your original attempt does not produce a meaningful constraint. Use the Timing Analyzer tool to produce a report of your timegroups to see exactly what pins are included in your original timegroups if you're not sure how timegroup formation works.Article: 104714
Hi Alan, I am going to get a project of this sort. So, I am just preparing for it. Regards, Srini. Alan Myler wrote: > srini wrote: > > > Hello experts, > > Would like to hear from you regarding the precautions, the common > > practices and problems that arise when migrating an ASIC RTL code into > > an FPGA. > > > > Thanks & Regards, > > Srini. > > Is this university homework or have you a specific project in mind? > > > What Fpga family are you migrating to? What Asic technology was the > RTL code originally targeted at? > > AlanArticle: 104715
John Williams schrieb: > Hi Antti, > > Antti wrote: > > MicroBlaze 4.0 has still to > > my knowledge issues with uClinux, > > details? I'm not aware of any issues, and there's no chatter about such on the > mb-uclinux list. > > John Dear John, google: uclinux microblaze 4 first hit http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/archive/2005/10/msg00111.html is link to the some chatter on the mb-uclinux I would assume readers of the uclinux list (some at least) are aware of the problem. to my knowledge there was never a plausible explanation why MB4 behaved badly with uclinux, but as I had issues with it on the platforms I am testing with then I have frozen my referecence design to MB version 3 - to guarantee that uclinux works in stable fashion. maybe the issue is gone by today, I will retest again to see if there are still problems or not Antti http://antti-brain.comArticle: 104716
I have few points here.. 1) Here, I assume that the reset we are talking about is the Power ON Reset which is connected to a switch (or equivalent ckt) in the board. If this is the case, then the reset period is much more higher than some miliseconds. 2) My point number 2 is reagrding putting some logic( SRL16, FFs..) in the reset ckt. I am afraid, it vilaotes the basic rule of controllability of DFT. I should be able to control the state of all the FFs from a single reset pin out side the chip. is not it true ? Of course, when we say it is a FPGA, then we assume that it is already tested and we should not be much worried about the DFT at this point. Some documents say that the Input reset should be asserted asyncronously and deasserted synchronously. This also make some sennse. Regards, Saumyajit Phil Hays wrote: > "StanleyLee" wrote: > > >Phil Hays wrote: > > >> If reset goes away in less than a clock period, then a single FF will > >> work, with enough care. Not a usual case anymore, unless the clock > >> rate is fairly slow. If reset takes multiple clocks to go away, but > >> less than 16, and the reset assertion time is longer than 16 clocks, > >> then a SRL16 is a very cheap and very good solution. This is a common > >> case. > > >Thanks for Phils answer, but how should I use the SRL16? In my opinion, > >if I do it as following, there is no difference between SRL16 and FF > >except there is 16 cycles delay when use SRL16. > > Exactly, and that difference may be required. > > Suppose your clock period is 2.5 ns, and the time required to > propagate asynchronous reset to all FFs is 25 ns. Then to make sure > that critical state was released from reset at the same time, then at > least 10 CLK cycles of delay would need to be added from the release > of asynchronous reset to the release of synchronous reset. > > An SRL16 (plus 2 FFs) would do this just fine, as would a 10 bit shift > register built out of FFs, or a 4 bit counter. The SRL16 uses the > smallest amount of hardware, there are reasons to use the other > methods at times. > > > -- > Phil Hays (Xilinx, but speaking for himself)Article: 104717
On 5 Jul 2006 00:07:24 -0700, saumyajit_tech@yahoo.co.in wrote: >2) My point number 2 is reagrding putting some logic( SRL16, FFs..) in >the reset ckt. I am afraid, it vilaotes the basic rule of >controllability of DFT. I should be able to control the state of all >the FFs from a single reset pin out side the chip. is not it true ? You can always insert control points after your reset logic so that when you enable test the flops become externally controllable again. It's easy to do this with current scan insertion tools.Article: 104718
"Robin Bruce" <robin.bruce@gmail.com> writes: > Martin, > > > Have you had a look in FPGA editor to see what's going on? > > This is where I myself look dim: I did open up the NCD file in the FPGA > Editor. I didn't really know what to do to tell if the right > registering was occurring. All I could see was that all 4 DSP48s were > instantiated together in a little row. I've never used FPGA editor > before. I'm more familiar with PlanAhead for looking at that sort of > thing, but I don't have that on my laptop, my current working platform. > I haven't looked at a V-4 in FPGA editor... but if you go to one of your DSP48 blocks and double click it, can you see the intrnals of it and are there some boxes that are filled in for the use of registers? > This is the critical path that comes out of the synthesis report if > this means anything to anyone: > > Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35 > Gate Net > Cell:in->out fanout Delay Delay Logical Name (Net Name) > ---------------------------------------- ------------ > DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001 > (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47) > DSP48:PCIN47->PCOUT47 1 2.363 0.000 > mult_inst/Mmult__n00002 > (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47) > DSP48:PCIN47->PCOUT47 1 2.363 0.000 > mult_inst/Mmult__n00003 > (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47) > DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004 > (mult_inst/Mmult__n0000_s_69) > FD:D 0.391 mult_inst/Mmult__n0000_0 > ---------------------------------------- > Total 12.320ns (11.786ns logic, 0.534ns route) > (95.7% logic, 4.3% route) > That looks like a cascade-chain... because your inputs are 35 bits wide and you use more than one multiplier, they need to cascade. This can be pipelined (by the look of the DSP48 diagram in UG073), but how you'd infer that I have no idea :-( You may have to infer the individual multipliers and the regs between them. But at that point, you might as well instantiate them! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 104719
Hi, I have been using "Ethernet Cores Hardware Demonstration Platform" with ML403 board and I got very good speed results with hard mac. But when I would like to synthesis that application I got problems, some errors appeared (I have no license for ethernet statistic and ppc IP cores - probably this is the reason). My questions is whether exists other application or sample(s) which I can synthesis and via which I can learn how to use the hard mac? Regards, MisiuArticle: 104720
On Tue, 04 Jul 2006 18:14:21 -0500, hmurray@suespammers.org (Hal Murray) wrote: > >>I think the pen analogy is valid... > >I use a ball rolling over a speed-bump. It's naturally only >one dimensional. I'm not convinced by these dynamics analogies. These are just unstable systems in an enery maxima, where a slight perturbation leads to a more stable, lower energy, configuration. In normal (my normal, anyway) usage of the term 'metastable', what's meant is an asychronous circuit with feedback, in which more than one input changes 'simultaneously', leading to oscillation because of a hazard. In practical circuits, the oscillation is damped and decays. Ok, in some practical circuits there may not be enough energy involved to actually switch a transistor and it may hold in an intermediate state for a significant time, but this is just a detail. Using this to describe general 'metastability' seems to me to be ignoring the big picture. EvanArticle: 104721
On Wed, 05 Jul 2006 10:40:41 +0100, Evan Lavelle <eml@nospam.co.uk> wrote: >Using this to >describe general 'metastability' seems to me to be ignoring the big >picture. Before you complain, I'm sure you're all quite capable of explaining the big picture as well... :)Article: 104722
Hello,
I am using Xilinx ISE 7.1 and VHDL for a project deployed in a Virtex2
FPGA. I place&route and then I run the static timing analyzer. Results
throw a timing constrain not met (see below). The weird thing is that
it happens after I removed some logic from the project, without adding
anything new. My understanding is that adding new logic could make
place&route harder, but removing logic would give us more room to find
a better allocation of resources. Any hints?
If it helps, related constrains are:
NET "gb_h3" DRIVE = 16 | SLEW = FAST ;
NET "tim_clkin" TNM_NET = "tim_clkin";
TIMESPEC "ts_tim_clkin" = PERIOD "tim_clkin" 25 ns HIGH 50 %;
offset = out 27ns after tim_clkin;
Timing Analyzer results (after and before removing the logic that
brought the problem):
=================================================================
Timing constraint: OFFSET = OUT 27 ns AFTER COMP "tim_clkin";
212 items analyzed, 31 timing errors detected.
Minimum allowable offset is 30.044ns.
--------------------------------------------------------------------------------
Slack: -3.044ns (requirement - (clock arrival + clock
path + data path + uncertainty))
Source:
i_dsp_n0_i_global_bus_link_i_GLOBAL_BUS_v241I875_Q3 (FF)
Destination: gb_a<3> (PAD)
Source Clock: gb_h3_OBUF falling at 12.500ns
Requirement: 27.000ns
Data Path Delay: 6.103ns (Levels of Logic = 2)
Clock Path Delay: 11.441ns (Levels of Logic = 3)
Clock Uncertainty: 0.000ns
Timing Improvement Wizard
Clock Path: tim_clkin to
i_dsp_n0_i_global_bus_link_i_GLOBAL_BUS_v241I875_Q3
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tiopi 0.793 tim_clkin
tim_clkin_IBUF
net (fanout=1) 3.345 tim_clkin_IBUF
Tbxxb 0.892 i_dsp_n0_i_global_bus_link_I_MUXCY_L
net (fanout=1) 4.295
i_dsp_n0_i_global_bus_link_I_MUXCY_L/O
Tgi0o 0.589 gb_h3_OBUF_BUFG
net (fanout=94) 1.527 gb_h3_OBUF
---------------------------- ---------------------------
Total 11.441ns (2.274ns logic, 9.167ns route)
(19.9% logic, 80.1% route)
Data Path: i_dsp_n0_i_global_bus_link_i_GLOBAL_BUS_v241I875_Q3 to
gb_a<3>
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tcko 0.568
i_dsp_n0_i_global_bus_link_i_GLOBAL_BUS_v241I875_Q3
net (fanout=2) 0.289 i_dsp_n0_gb_addr_bus<3>
Tilo 0.439 i_dsp_n0_i_global_bus_link_GBADDR<3>1
net (fanout=1) 1.164 gb<0>_o_addr<3>
Tioop 3.643 gb_a_3_OBUFT
gb_a<3>
---------------------------- ---------------------------
Total 6.103ns (4.650ns logic, 1.453ns route)
(76.2% logic, 23.8% route)
==================================================================
Timing constraint: OFFSET = OUT 27 ns AFTER COMP "tim_clkin";
212 items analyzed, 0 timing errors detected.
Minimum allowable offset is 26.342ns.
--------------------------------------------------------------------------------
Slack: 0.658ns (requirement - (clock arrival + clock
path + data path + uncertainty))
Source:
i_dsp_n0_i_global_bus_link_i_GLOBAL_BUS_v241I876_Q6 (FF)
Destination: gb_a<22> (PAD)
Source Clock: gb_h3_OBUF falling at 12.500ns
Requirement: 27.000ns
Data Path Delay: 7.233ns (Levels of Logic = 2)
Clock Path Delay: 6.609ns (Levels of Logic = 3)
Clock Uncertainty: 0.000ns
Clock Path: tim_clkin to
i_dsp_n0_i_global_bus_link_i_GLOBAL_BUS_v241I876_Q6
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tiopi 0.793 tim_clkin
tim_clkin_IBUF
net (fanout=1) 1.420 tim_clkin_IBUF
Tbxxb 0.892 i_dsp_n0_i_global_bus_link_I_MUXCY_L
net (fanout=1) 1.399
i_dsp_n0_i_global_bus_link_I_MUXCY_L/O
Tgi0o 0.589 gb_h3_OBUF_BUFG
net (fanout=93) 1.516 gb_h3_OBUF
---------------------------- ---------------------------
Total 6.609ns (2.274ns logic, 4.335ns route)
(34.4% logic, 65.6% route)
Data Path: i_dsp_n0_i_global_bus_link_i_GLOBAL_BUS_v241I876_Q6 to
gb_a<22>
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tcko 0.568
i_dsp_n0_i_global_bus_link_i_GLOBAL_BUS_v241I876_Q6
net (fanout=2) 0.286 i_dsp_n0_gb_addr_bus<22>
Tilo 0.439
i_dsp_n0_i_global_bus_link_GBADDR<22>1
net (fanout=1) 2.307 gb<0>_o_addr<22>
Tioop 3.633 gb_a_22_OBUFT
gb_a<22>
---------------------------- ---------------------------
Total 7.233ns (4.640ns logic, 2.593ns route)
(64.2% logic, 35.8% route)
Article: 104723misiu wrote: > Hi, > > I have been using "Ethernet Cores Hardware Demonstration Platform" with > ML403 board and I got very good speed results with hard mac. But when I > would like to synthesis that application I got problems, some errors > appeared (I have no license for ethernet statistic and ppc IP cores - > probably this is the reason). > My questions is whether exists other application or sample(s) which I > can synthesis and via which I can learn how to use the hard mac? > > Regards, > Misiu Take a look at www.xilinx.com/mpmc2 where you can download the latest MPMC2 software with included high performance Gigabit System Reference Design (GSRD) in GRSD2/projects/ml403_ddr_idpoc_100mhz_gsrd.zip designed for ML403. GuruArticle: 104724
hi how can i instantiate EDN core (exported from PlanAhead) in top level of a verilog design , while the core doesnot have any associated I/O buffers and gives same error in ISE mapping.
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