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
Andrew can you send me your email so that an engineer can contact you on this. Thanks for the test case and we are working on it. Subroto Datta Altera Corp.Article: 82451
Jeff Cunningham wrote: > Antti Lukats wrote: > >> "Steve" <smkraft@pacbell.net> schrieb im Newsbeitrag >> news:1113327700.042531.314340@l41g2000cwc.googlegroups.com... >> >>> I am looking for some information about how "real" this soft CPU >>> technology is. I'm working with someone who has become enamored with >>> the "soft CPU" concept from the FPGA vendors. I have a number of what >>> seem to me to be "gotta know" questions about this technology, and I >>> don't know how to get them answered. There are big picture questions >>> like: >>> >>> - What are the compelling reasons to go this route? >> >> >> >> 1) no obsolence >> 2) build your system with the peripherals and functions you need >> 3) design hardware after its has been manufactured to speed up time to >> market, the hardware is only bitstream and can be updated softly, also >> you >> can rework early design errors without the PCB changes >> 4) flexibility, design to be future safe, new hardware features can be >> added >> after product hardware is manufactured >> 5) etc.. > > > As a practical matter, don't all of these points also apply to an > external uC with an FPGA as a peripheral? Also, I'm a little perplexed > by point 1 - no obsolescence - don't FPGAs families become obsolete > just like anything else? Or do you mean something else? I think the point here is that it gives high confidence that today's soft CPU design, targeted to say a Spartan3, will still be able to be synthesised into a spartan10, XX years down the track. In contrast, developing a product with a fixed silicon embedded processor + peripheral set - if it just so happens that you choose a CPU+peripheral combo that doesn't sell so well, there's every likelihood it will be end-of-lifed before too long. Remembering of course that you don't just buy "a coldfire" (or an 8051, or whatever), but rather devices in this space are bundled with various options on the silicon - the number of combinations is finite, and you are at the mercy of the silicon providor to continue supplying *that specific combo* into the future. FPGAs being generic means that you can be sure to implement the same digital system (eg CPU + peripheral combo) for as long as you want. John > > -JeffArticle: 82452
You have to distinguish between specs abd eality. The output voltage specs for LVCMOS and LVTTL are different, for historical reasons, since CMOS pulls up to the rail, and TTL traditionally had two diode drops below Vcc, therefore the 2.4 V (going back to T.I. in the 'sixties) In reality, the two types of outputs are the same, and "both" pull up to the rail. Similarily with Vol = 0.4 V. That stems from bipolar outputs that never reach ground. In CMOS (and all FPGAs are CMOS) the Vol at zero current is really zero volt. We carry a lot of distracting baggage, accumulated during 40 years of digital IC evolution... Peter AlfkeArticle: 82453
gja wrote: > Would he be able to apply some timing constraints to the flops in > block C and maybe the clock to block C to guarantee that the clock > skew is acceptable. [this is in regards to using local routing for the clk in block C] In theory, yes. In practice, the number of flops that the tools can route to with similar prop delay (aka low-skew) is limited. Wild guess: a couple hundred FF's might be reachable. Maybe more, maybe less. And it would not be surprising to me if most or all of them needed to be hand placed. MarcArticle: 82454
Delbert Cecchi wrote: > I was referring to the US Electronic Intelligence or something plane > that got kidnapped out of international airspace near china and forced > to land. Got the crew back in a while. As I recall we got the airframe > back in boxes. It was rumored the crew didn't have enough time to > destroy all. Probably within last 10 or so years. Google should turn > it up. EC137 may have been the aircraft type. A Chinese F-8 and a US EP-3 collided during an intercept; the F-8 was lost and the EP-3 performed an emergency landing at Hainan airfield. A fairly standard cock-up between great powers. KellyArticle: 82455
"Marc Randolph" <mrand@my-deja.com> wrote in message news:<1113311589.903268.83150@z14g2000cwz.googlegroups.com>... > Howdy, > > Depending on how you are getting signals between blocks A/B and C, > there is the potential for trouble - but the MUCH bigger problem is > that you will have unacceptable skew *within* block C. Unless you > floorplan the flops within block C (and do so VERY intelligently), > you're asking for trouble. Even if you do the muxing with LUTs, send > the output of the LUT to a global clock. > > And yes, the skew within blocks A and B should be fine. > > Marc Could you clarify this point ? Why shouldn't the skew inside block C be low, assuming it is also an a global clock line ? ThanksArticle: 82456
Bret Wade wrote: > Hi Rudi, > > We've seen one similar case and that was a Windows only failure. If you > have access to a Linux or Solaris machine, that might work. On the other > hand, that case wasn't an SP1 regression like yours is, so they may be > different problems. If that doesn't work, a webcase would be the next > suggestion. > > Regards, > Bret Bret, the reported problem occurred on a Linux system. We only use a windows notebook for downloading of bit streams and ChipScope, otherwise only Linux. Best Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and SynthesisArticle: 82457
Hello ALl; Could anyone provide me with useful link about the design of a MIMO system for channel estimation in the uplink channel of WCDMA ? Thanks in advance. MohamedArticle: 82458
Unfortunately wrote: > > Rudolf Usselmann wrote: >> It's been now several weeks since the release of 7.1. However >> I still have not seen a "fix" that would allow us to install >> ISE 7.1 on 64 bit platforms: >> >> [rudi@cpu10 ISE71i_DesignEnv_lin64]$ ./setup >> /home/tmp/7.1/ISE71i_DesignEnv_lin64/platform/lin64/bin/lin64 >> /home/tmp/7.1/ISE71i_DesignEnv_lin64/platform/lin64/xilsetup: Symbol >> `_XtperDisplayList' causes overflow in R_X86_64_PC32 relocation >> /home/tmp/7.1/ISE71i_DesignEnv_lin64/platform/lin64/xilsetup: Symbol >> `_XtGetPerDisplayInput' causes overflow in R_X86_64_PC32 relocation >> Wind/U Error (294): Unable to install Wind/U ini file >> (/home/tmp/7.1/ISE71i_DesignEnv_lin64/platform/lin64/data/WindU). >> See the Wind/U manual for more details on the ".WindU" file and the > "WINDU" >> environment variable. >> /home/tmp/7.1/ISE71i_DesignEnv_lin64/platform/lin64/setup: line 163: > 19510 >> Segmentation fault (core dumped) $setuploc/xilsetup $switch > $batchfile >> >> >> ************ setup done! *************** >> >> Will xilinx ever release a setup program that works, or do we >> have to wait for 7.2 ? > > Howdy Rudi, > > I don't know if your posting prompted it, but two days after you > posted, an answer record is now avaialble on this issue: > > http://support.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=21000 > > Good luck, > > Marc Thanks for the pointer Marc ! Unfortunately I am using a "unsupported OS" (FC3) ... So I guess I am out of luck using 7.1 64 bit ... I have tried making sure all xilinx environment variables are not set, and that the installation directory is empty - I am still getting seg. fault ... Thanks ! rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and SynthesisArticle: 82459
Hi Subroto, first thanks to you and all the other people here helping me out! > Now, as for VHDL libraries: Prior to Quartus II 4.2, all user VHDL > source files were compiled into the WORK library. In 4.2, we still > compile VHDL source files into WORK by default, but we also added > several mechanisms that allow the user to specify a different > destination library. These mechanisms are described in the Quartus II > Handbook, Chapter 6: > http://www.altera.com/literature/hb/qts/qts_qii51008.pdf o.k., there is stated: <quote> Unlike the MAX+PLUS® II software and earlier versions of the Quartus II software, Quartus II software versions 2.1 and later do not support pre-compiled libraries. </quote> was there a special reason (of course there was :P) to drop this feature? When I write "my_lib" to File -> File Properties -> Library for the packages I want to be part of "my_lib" things work as desired. But the vhdl "library" is not reflected in the file system like new directory or similar. Am I right in the assumption that the library mechanism only allows to group elements in libraries within one single project and not to generate a library that then can be passed around and used in other projects _as Library_? A last question: Is the library name I entered (as described above) as proberty of a VHDL file in any way related to libraries listed in Assignments -> Settings -> User Libraries? Best regards and thanks again, /chArticle: 82460
Subroto Datta wrote: > Andrew can you send me your email so that an engineer can contact you > on this. Thanks for the test case and we are working on it. > > Subroto Datta > Altera Corp. Thanks. My e-mail is here http://www.holmea.demon.co.uk/IMG/email.gifArticle: 82461
"Stephane" <stephane@nospam.fr> wrote in message news:d3dfqf$hib$1@ellebore.extra.cea.fr... > Did you consider using CMOS imagers? They have the great advantage that > you can focus on a (or several) ROI. > > C. Peter wrote: > > Hi all, > > > > some years have gone since I did something with FPGAs and I am aware > > that technology has moved forward significantly since the end of the > > last century ... > > > > We now think about reading out some CCD sensors and doing image > > processing with an FPGA. My questions to you: > > - do you think this is feasable? > Sure, but what kind of application? A simple one can be done in software. > > > - which FPGA would you recommend? > Again, what algorithms, what size of image, how many images/second... > and most important, how much are you eager to spend for each device? > > > - Which language would you recommend? > No other choice yet than Verilog/VHDL... > > > > > We have used Xilinx and Handel-C so far and hence would prefer to stick > > to them. But if there are good arguments against it we would certainly > > follow them. > > > > Thanks a lot for your advice, > > > > Christian > > Correct. CMOS sensors has also evolved forward significantly since the beginning of this century. If you are not expecting the CCD type of image quality, CMOS delivers the higher quantity of pixels at lower cost than CCD. This website is helpful to you. http://www.elphel.com/3fhlo/Article: 82462
Hi Frank, I find three .bmm files: controller.bmm controller_stub.bmm controller_mb.bmm But all these files are equal: // File: D:\xilinx\test_projects\test8\implementation\controller_stub.bmm ADDRESS_BLOCK lmb_bram RAMB16 [0x00000000:0x00003fff] BUS_BLOCK u1/lmb_bram/lmb_bram/ramb16_s4_s4_0 [31:28] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_1 [27:24] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_2 [23:20] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_3 [19:16] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_4 [15:12] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_5 [11:8] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_6 [7:4] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_7 [3:0] ; END_BUS_BLOCK; END_ADDRESS_BLOCK; John På Tue, 12 Apr 2005 16:39:13 +0200, skrev Frank van Eijkelenburg <someone@work.com>: > If you choose for import, do you choose the right .bmm file? It should be > something like system_stub_bd.bmm. If you choose the wrong one, your > microblaze won't run. > > Frank > > > "John" <nospam.nospam@nospam.com> wrote in message > news:opso4g8cafg6mgav@visitech-jd.visitech.local... >> >> I feel more and more stupid here, because I cannot figure this out. I >> have >> now followed your steps but still no running microblaze. >> >> These are the steps I am following: >> First I build a XPS system, then I export this. I do some modification >> to >> the system_stub.vhd with regard to instatiated buffers then I run a P&R >> with other VHDL. Finally I import the result into XPS. >> >> I have "Mark to Initialize BRAMs" set then I run update bitstream (as >> you >> said). I download the resulting bit file using IMPACT. The VHDL part of >> the system is running but the microblaze seems to be stuck. Something I >> miss now? >> >> >> >> >> >> >> På Tue, 12 Apr 2005 13:02:15 +0200, skrev Antti Lukats >> <antti@openchip.org>: >> >> >> >> >> >> -- >> Sendt med M2 - Operas revolusjonerende e-postprogram: >> http://www.opera.com/m2/ > > -- Sendt med M2 - Operas revolusjonerende e-postprogram: http://www.opera.com/m2/Article: 82463
Hi John,
if that the case then they are ALL WRONG, I forgot aboutt the .BMM issue I
used to fight with a LOT some while ago. Thats one reason why I did say that
you should not use import export with XPS
you need a file that looks like
lmb_bram/lmb_bram/ramb16_s2_s2_0 [31:30] PLACED = X0Y11;
lmb_bram/lmb_bram/ramb16_s2_s2_1 [29:28] PLACED = X0Y9;
the "PLACED ." is important this info is by the XPS flow to actually merge
the SW and HW, it tells where the individual BRAMs are located.
if that file is wrong then all SW bits will be around the chip in random
BRAM locations
XPS generated this file in \implementation directory, if you use ISE to
synthesize then ISE must know have assigned BMM to the BMM with PLACED, only
then will the ISE generated bitstream actually match to what XPS expects.
as said, this may be very painful to setup, after you export, then in ISE
try to add the BMM with 'placed' to the project, if that does not work then
you must use the PLACED BMM from XPS implementation, then create UCF lock
file locking all BRAMS to what they are in the XPS PLACED BMM then rerun ISE
with the BRAM constrained .UCF file then import to XPS and use the original
BMM that XPS created.
That must work. It was problematic and painful a few EDK versions ago, and
as you have problems it looks like the problem still perstists.
antti
"John" <nospam.nospam@nospam.com> schrieb im Newsbeitrag
news:opso5v5pnbg6mgav@visitech-jd.visitech.local...
> Hi Frank,
>
> I find three .bmm files:
> controller.bmm
> controller_stub.bmm
> controller_mb.bmm
>
> But all these files are equal:
>
> // File: D:\xilinx\test_projects\test8\implementation\controller_stub.bmm
>
> ADDRESS_BLOCK lmb_bram RAMB16 [0x00000000:0x00003fff]
> BUS_BLOCK
> u1/lmb_bram/lmb_bram/ramb16_s4_s4_0 [31:28] ;
> u1/lmb_bram/lmb_bram/ramb16_s4_s4_1 [27:24] ;
> u1/lmb_bram/lmb_bram/ramb16_s4_s4_2 [23:20] ;
> u1/lmb_bram/lmb_bram/ramb16_s4_s4_3 [19:16] ;
> u1/lmb_bram/lmb_bram/ramb16_s4_s4_4 [15:12] ;
> u1/lmb_bram/lmb_bram/ramb16_s4_s4_5 [11:8] ;
> u1/lmb_bram/lmb_bram/ramb16_s4_s4_6 [7:4] ;
> u1/lmb_bram/lmb_bram/ramb16_s4_s4_7 [3:0] ;
> END_BUS_BLOCK;
> END_ADDRESS_BLOCK;
>
>
> John
>
>
>
>
> På Tue, 12 Apr 2005 16:39:13 +0200, skrev Frank van Eijkelenburg
> <someone@work.com>:
>
> > If you choose for import, do you choose the right .bmm file? It should
be
> > something like system_stub_bd.bmm. If you choose the wrong one, your
> > microblaze won't run.
> >
> > Frank
> >
> >
> > "John" <nospam.nospam@nospam.com> wrote in message
> > news:opso4g8cafg6mgav@visitech-jd.visitech.local...
> >>
> >> I feel more and more stupid here, because I cannot figure this out. I
> >> have
> >> now followed your steps but still no running microblaze.
> >>
> >> These are the steps I am following:
> >> First I build a XPS system, then I export this. I do some modification
> >> to
> >> the system_stub.vhd with regard to instatiated buffers then I run a P&R
> >> with other VHDL. Finally I import the result into XPS.
> >>
> >> I have "Mark to Initialize BRAMs" set then I run update bitstream (as
> >> you
> >> said). I download the resulting bit file using IMPACT. The VHDL part of
> >> the system is running but the microblaze seems to be stuck. Something I
> >> miss now?
> >>
> >>
> >>
> >>
> >>
> >>
> >> På Tue, 12 Apr 2005 13:02:15 +0200, skrev Antti Lukats
> >> <antti@openchip.org>:
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Sendt med M2 - Operas revolusjonerende e-postprogram:
> >> http://www.opera.com/m2/
> >
> >
>
>
>
> --
> Sendt med M2 - Operas revolusjonerende e-postprogram:
> http://www.opera.com/m2/
Article: 82464hello, i am using RLOC statement as .. //synthesis attribute rloc of d1 is X12Y11 As far as i understand, these X-Y co-ordinates specify the Slice number. My first question is - how do i specify which of the two flip-flops(in one slice) to use? .. i was going thru the documentation, where i noticed RLOC_RANGE option, has anybody used this option. i tried it as - //synthesis attribute RLOC_RANGE of d1 is X0Y0:X2Y2 the MAP failed and reported, ERROR:Map:10 - RLOC_RANGE attribute on FD symbol "d1" (output signal=t) must be on the start of a set. What am i doing wrong? thanks, varunArticle: 82465
Hi Ray, Ray Andraka wrote: > Brendan Cullen wrote: > > >Hi, > > > > > >If you're targeting V4 then you are targeting one of our SX or LX devices > >and you are using 7.1.01i. > > > > > > > not necessarily. I'm targeting an SX55 and using 6.3sp3. I agree that you can use ISE to target the SX55 using 6.3sp3. But XPower is a different kettle of fish to the other tools in ISE. XPower's SX & LX support was only added after silicon-based characterisation was performed. This support for SX & LX was added to XPower in 7.1.01i. By the way - 7.1.01i allows an FX design to be opened in XPower. That is a bug - and has been corrected in 7.1.02i. 7.1.02i is scheduled for availability in late April. I hope this clarifies things, Brendan > > > -- > --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, 1759Article: 82466
You can always search the answer at the www.altera.com. For MAX® 7000S devices, they are shipped blank but have specific bits set to tri-state all their I/O pins. If the part is erased, it is blank, but the factory default tri-state bit settings are also erased and therefore pins will no longer be tri-stated. To tri-state the blank part again, you need to have the blank POF (programming object file) from a factory shipped blank device that has never been programmed. You can get the blank POF by examining a factory shipped MAX 7000S device using the MAX+PLUS II software (Quartus II does not support examine for MAX 7000S); the examined POF will be blank but will have the tri-state bit settings. Programming a MAX 7000S device with this POF will tri-state the I/Os and blank the design. MAX 7000AE, MAX 3000A, and MAX 7000B devices differ from MAX 7000S - if the part is blank or erased it will automatically tri-stated the all the I/O pins and does not need tri-state bit settings. If you erase these devices, they will tri-state all I/Os. This is because MAX 7000AE, MAX 3000A, and MAX 7000B remain tri-state until a specific bit is set during ISP called the ISP_DONE bit. It is the last bit to be programmed when programming the device - if that bit is not set, the device remains tri-stated. All MAX3000A, 7000S, 7000A, 7000B, and MAX II devices are shipped blank from the factory. When a blank device is powered up, all of the I/O pins are tri-stated. If you erase a MAX 3000A, 7000A, 7000B, or MAX II device it behaves the same as a blank new factory shipped device. The I/O pins of a blank device are tri-stated when powered. However, this is not true for MAX 7000S. A new factory shipped MAX 7000S device will tri-state when powered, but if this device is erased in some manner (Jam, JBC, SVF, etc), then the I/O pins will drive out undetermined values. This is because a new factory shipped MAX 7000S part is blank except for some OE control bits which are set to tri-state the I/O pins. When erased, those OE bits are cleared and the I/O pins drive out. The only way to get the I/O pins to tri-state again is if the customer examined and saved the .pof from a new factory shipped MAX 7000S device. Program a MAX 7000S with that .pof and it will behave the same as the new factory shipped part, that is it will be blank with tri-stated I/Os. Here is the link http://answers.altera.com/altera/resultDisplay.do?page=http%3A%2F%2Fwww.altera.com%2Fsupport%2Fkdb%2F2003%2F12%2Frd12082003_9642.html&result=0&responseid=45b50f58f81c41c5%3A576e70%3A10338fea6ab%3A6f47&groupid=1&contextid=5179%3A1971.2113%2C1625.1759%2C1827.1970&clusterName=DefaultCluster&doctype=1000&excerpt=Program+a+MAX+7000S+with+that+.pof+and+it+will+behave+the+same+as+the+new+factory+shipped+ art%2C+that+is+it+will+be+blank+with+tri-stated+I%2FOs.#Goto1971 http://answers.altera.com/altera/resultDisplay.do?page=http%3A%2F%2Fwww.altera.com%2Fsupport%2Fkdb%2F2004%2F09%2Frd09092004_5239.html&result=3&responseid=45b50f58f81c41c5%3A576e70%3A10338fea6ab%3A6f4d&groupid=1&contextid=5514%3A1785.1980%2C1044.1152&clusterName=DefaultCluster&doctype=1000&excerpt=MAX+7000AE%2C+MAX+3000A%2C+and+MAX+7000B+devices+differ+from+MAX+7000S+-+if+the+part+is+blank+or+erase +it+will+automatically+tri-stated+the+all+the+I%2FO+pins+and+does+not+need+tri-state+bit+settings.#Goto1785 Ben Twijnstra <btwijnstra@gmail.com> wrote in message news:<BIV6e.62768$Sc7.16377@amsnews05.chello.com>... > Hi Andrew Holme, > > > Ben Twijnstra wrote: > >> Hi Andrew, > >> > >>>> Blank that sample and see what happens ;-) > >>> > >>> How do I do that? Is there an option in Quartus for this? I > >>> couldn't see anything .... > >> > >> Wups... I don't have an actual EPM7128S device lying around here, but > >> from the command line try "quartus_pgm --operation=R". If you need > >> more help, type "quartus_pgm --help=operation". > > > > This is what I'm getting: > > > > C:\>quartus_pgm -c "ByteBlasterMV [LPT1]" -m JTAG --operation=R > > Error: Programming option string R is illegal. Refer to --help for legal > > programming option formats. > > > > The help says: > > > > <options> must be one of the following combinations: > > P, V, B, S, E, L, PVBL, PBL, PVB, PVL, PL, VL > > where > > P = Program V = Verify > > B = Blank-check L = Lock/Security Bit > > S = Skip/Bypass* E = Examine* > > (* Cannot be used in combination with other options) > > > > There doesn't appear to be an R option. > > > > I'm using Quartus II Programmer Version 4.1 Build 181 06/29/2004 SJ Web > > Edition > > > > Does this version have an erase option? > > Hmmm... I'm using a beta of version 5.0 (only available under NDA), which > does have the option available. > > Will try 4.2 tomorrow - that's the oldest workable version I have laying > around (I also have a copy of 3.0 and the initial 1996 release, but I don't > count those as current). > > Best regards, > > > > BenArticle: 82467
Kar wrote: > You can always search the answer at the www.altera.com. > [snip: text of articles] Thanks for the lead. For the benefit of others, those expired links are: http://www.altera.com/support/kdb/2004/09/rd09092004_5239.html http://www.altera.com/support/kdb/2003/12/rd12082003_9642.html Perhaps the most useful link for me, since I don't have the old MAX+PLUS II software, and can't use "Examine" to create a POF file from a fresh factory-shipped device, is this link which explains how to blank a MAX7000S device using the JAM player: http://www.altera.com/support/kdb/1999/09/rd09131999_640.htmlArticle: 82468
Andrew Holme wrote: > Kar wrote: > > You can always search the answer at the www.altera.com. > > > > [snip: text of articles] > > Thanks for the lead. > > For the benefit of others, those expired links are: > http://www.altera.com/support/kdb/2004/09/rd09092004_5239.html > http://www.altera.com/support/kdb/2003/12/rd12082003_9642.html > > Perhaps the most useful link for me, since I don't have the old > MAX+PLUS II software, and can't use "Examine" to create a POF file from > a fresh factory-shipped device, is this link which explains how to > blank a MAX7000S device using the JAM player: > > http://www.altera.com/support/kdb/1999/09/rd09131999_640.html After re-eading the above, I'm not sure if the JAM player "erase" method is an "erase" or a "blank" as defined in the other articles i.e. does it tri-state the I/O pins?Article: 82469
Andrew Holme wrote: > Andrew Holme wrote: > > Kar wrote: > > > You can always search the answer at the www.altera.com. > > > > > > > [snip: text of articles] > > > > Thanks for the lead. > > > > For the benefit of others, those expired links are: > > http://www.altera.com/support/kdb/2004/09/rd09092004_5239.html > > http://www.altera.com/support/kdb/2003/12/rd12082003_9642.html > > > > Perhaps the most useful link for me, since I don't have the old > > MAX+PLUS II software, and can't use "Examine" to create a POF file > from > > a fresh factory-shipped device, is this link which explains how to > > blank a MAX7000S device using the JAM player: > > > > http://www.altera.com/support/kdb/1999/09/rd09131999_640.html > > After re-eading the above, I'm not sure if the JAM player "erase" > method is an "erase" or a "blank" as defined in the other articles i.e. > does it tri-state the I/O pins? OK, having gone round the loop one last time (this blank/erased business is very confusing!) I believe that reading a blank POF is (quote) "The only way to get the I/O pins to tri-state again" - so I'm hosed.Article: 82470
Hi,
I'm using EDK 6.3i under linux (release 12.3) and I'm trying to
instantiate an ethernet controller on my virtex 4 board (avnet
xc4vlx25). I'm always getting errors from the PAR tool saying that
timing constraints are not met, even if I try harder to synthetize.
I've tried a lot of different options in synthetizing and place and
route tools, but nothing changes, and now I just don't have any idea of
what I could try. As I'm using the builtin ethernet controller, I'm not
supposed to modify anything in the design of it I suppose, so what
could I try? Is it possible to build a valid system by ignoring timing
constraints?
I include the report of the PAR tool in the message:
Starting initial Timing Analysis. REAL time: 12 secs
ERROR:Par:228 - PAR: At least one timing constraint is impossible to
meet
because component delays alone exceed the constraint. A physical
timing
constraint summary follows. This summary will show a MINIMUM net
delay for
the paths. Please use the Timing Analyzer (GUI) or TRCE (command
line) with
the Mapped NCD and PCF files to identify the problem paths. For
more
information about the Timing Analyzer, consult the Xilinx Timing
Analyzer
Reference manual; for more information on TRCE, consult the Xilinx
Development System Reference Guide "TRACE" chapter.
Asterisk (*) preceding a constraint indicates it was not met.
This may be due to a setup or hold violation.
--------------------------------------------------------------------------------
Constraint | Requested | Actual |
Logic
| | |
Levels
--------------------------------------------------------------------------------
NET "ETH_RXC_BUFGP" MAXSKEW = 2 nS | 2.000ns | 0.000ns |
N/A
--------------------------------------------------------------------------------
* NET "ETH_RXC_BUFGP" PERIOD = 40 nS HIG | 40.000ns | 5.480ns |
2
H 14 nS | | |
--------------------------------------------------------------------------------
NET "ETH_TXC_BUFGP" MAXSKEW = 2 nS | 2.000ns | 0.000ns |
N/A
--------------------------------------------------------------------------------
* NET "ETH_TXC_BUFGP" PERIOD = 40 nS HIG | 40.000ns | 2.033ns |
1
H 14 nS | | |
--------------------------------------------------------------------------------
TSTXOUT_ethernet = MAXDELAY FROM TIMEGRP | 10.000ns | 3.261ns |
1
"TXCLK_GRP_ethernet" TO TIMEGRP "PADS" 10 | | |
nS | | |
--------------------------------------------------------------------------------
* TSRXIN_ethernet = MAXDELAY FROM TIMEGRP " | 6.000ns | 6.350ns |
2
PADS" TO TIMEGRP "RXCLK_GRP_ethernet" 6 n | | |
S | | |
--------------------------------------------------------------------------------
TSCLK2CLK90_ddr_controller = MAXDELAY FRO | 2.875ns | 1.376ns |
0
M TIMEGRP "OPB_Clk_ddr_controller" TO TIM | | |
EGRP "Clk90_in_ddr_controller" 2.875 nS | | |
--------------------------------------------------------------------------------
3 constraints not met.
INFO:Timing:2761 - N/A entries in the Constraints list may indicate
that the
constraint does not cover any paths or that it has no requested
value.
Bertrand Rousseau
Article: 82471As you saw inother post, all bmm files are invalid (in the sense that they cannot used by xps to merge the software in the generated bit file). I agree with this ;) If I look at a project I did with a microblaze (project name is bootldr and microblaze is used as submodule) I see the following: - after creating netlist (in xps) two bmm files are created in the implementation directory (bootldr.bmm and bootldr_stub.bmm) - add the bmm file with the name ..._stub.bmm to your ISE project - build the final bit file - choose for import in xps and import the by ISE generated bit file and the generated bmm file with the name ..._stub_bd.bmm (the bmm file exists in the implementation directory) - choose for initialize bram and in the implementation your final bit file is called download.bit (in the implementation directory) this should work. Frank "John" <nospam.nospam@nospam.com> wrote in message news:opso5v5pnbg6mgav@visitech-jd.visitech.local... > Hi Frank, > > I find three .bmm files: > controller.bmm > controller_stub.bmm > controller_mb.bmm > > But all these files are equal: > > // File: D:\xilinx\test_projects\test8\implementation\controller_stub.bmm > > ADDRESS_BLOCK lmb_bram RAMB16 [0x00000000:0x00003fff] > BUS_BLOCK > u1/lmb_bram/lmb_bram/ramb16_s4_s4_0 [31:28] ; > u1/lmb_bram/lmb_bram/ramb16_s4_s4_1 [27:24] ; > u1/lmb_bram/lmb_bram/ramb16_s4_s4_2 [23:20] ; > u1/lmb_bram/lmb_bram/ramb16_s4_s4_3 [19:16] ; > u1/lmb_bram/lmb_bram/ramb16_s4_s4_4 [15:12] ; > u1/lmb_bram/lmb_bram/ramb16_s4_s4_5 [11:8] ; > u1/lmb_bram/lmb_bram/ramb16_s4_s4_6 [7:4] ; > u1/lmb_bram/lmb_bram/ramb16_s4_s4_7 [3:0] ; > END_BUS_BLOCK; > END_ADDRESS_BLOCK; > > > John > > > > > På Tue, 12 Apr 2005 16:39:13 +0200, skrev Frank van Eijkelenburg > <someone@work.com>: > >> If you choose for import, do you choose the right .bmm file? It should be >> something like system_stub_bd.bmm. If you choose the wrong one, your >> microblaze won't run. >> >> Frank >> >> >> "John" <nospam.nospam@nospam.com> wrote in message >> news:opso4g8cafg6mgav@visitech-jd.visitech.local... >>> >>> I feel more and more stupid here, because I cannot figure this out. I >>> have >>> now followed your steps but still no running microblaze. >>> >>> These are the steps I am following: >>> First I build a XPS system, then I export this. I do some modification >>> to >>> the system_stub.vhd with regard to instatiated buffers then I run a P&R >>> with other VHDL. Finally I import the result into XPS. >>> >>> I have "Mark to Initialize BRAMs" set then I run update bitstream (as >>> you >>> said). I download the resulting bit file using IMPACT. The VHDL part of >>> the system is running but the microblaze seems to be stuck. Something I >>> miss now? >>> >>> >>> >>> >>> >>> >>> På Tue, 12 Apr 2005 13:02:15 +0200, skrev Antti Lukats >>> <antti@openchip.org>: >>> >>> >>> >>> >>> >>> -- >>> Sendt med M2 - Operas revolusjonerende e-postprogram: >>> http://www.opera.com/m2/ >> >> > > > > -- > Sendt med M2 - Operas revolusjonerende e-postprogram: > http://www.opera.com/m2/Article: 82472
I am just wondering if i simulate a design given in verilog using a test fixure in a modern simulator like ModelSim and the outputs are verified, what are the chances that the design will still not work in the actual FPGA assuming it fits and Place and Route is successful. What are the factors that make this difference and how can i catch them in the design cycle. I am actually creating few designs for DSP algos for my acadmic project, and being a beginnner in this whole DSP over FPGA I find it rather difficult to decide wather to call a successful simulation a milestone in the design cycle or not. Please share your experiences and ideas on thisArticle: 82473
"Peter Alfke" <alfke@sbcglobal.net> wrote in message news:<1113362657.039477.81570@z14g2000cwz.googlegroups.com>... [LVTTL and LVCMOS33] > In reality, the two types of outputs are the same, and "both" pull up > to the rail. That were my guess, but I usually try to stick to the exact wording of a specification, only to be sure. Wouldn't it be possible to write the more stringent values to the Xilinx specs, independent of what JEDEC (or whatever) says? In some corner cases (such as the ATA/ATAPI requirements) this may help a bit. Currently I have a similar problem with a microcontroller specification: The given values may reflect maximum worst case, but are that pessimistic that they don't help at all. Sebastian WeiserArticle: 82474
Hi all, This is a basic qustion regarding SDA and SCL pins. Since both these pins are bidirectional these should pins need to be tristated , so that the slave can acknowledge on SDA. But i have seen in some docs that a '1' need to be converted to a 'Z' while driving on SDA and SCL, what is the reason behind this???? Thanks in advance, Praveen
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