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
"Joel Kolstad" <JKolstad71HatesSpam@yahoo.com> wrote in message news:12m3qjn4fcl0jec@corp.supernews.com... > I hope that the "students are not to be trusted with untyped languages" idea > is universal That should be "ISN'T" universal.Article: 112326
Antti wrote: > tullio schrieb: > > > It's about a year that Spartan3E are on the market but i am still > > confused on pricing. > > On: http://www.xilinx.com/products/spartan3e/faq105-sp3e.pdf xilinx > > states that > > XC3S1200E is less than $9. > > > > On the major distributors (Nu Horizons, Avnet) the same part goes for > > about $45. > > Is $9 a marketing thing only, or is there any chance that quantity > > prices will drop to that level ? > > > > tullio > > did you ask quote for 500,000 pieces single order? its clearly stated > this is possible price for 0.5M pieces orders only. > > for smaller orders you may be able to get the price down to around $20 > USD slowest speed cheapest package, but dont expect prices below that > unless you are really buyins millions of pieces. I seriously doubt the 1200 will see $20 even in the smallest package unless you are looking at a huge number. I had a quote on the 3S400 in the FG456 at qty 50k and it was still only $20. the 1200 is three times larger and even in the FG256 package it is going to cost a bit. Like Antti said, the published numbers are for literally million piece orders, and even then only if you beat them about the head and shoulders. That is why it is economically to your advantage to design your product so you can use more than one brand of FPGAs. Then you can leverage a competitive bid and literally get half the price you might get otherwise. The vendors (at least the Xilinx vendors) will try to tell you the best way to save $$$ on the chips is to tailor your code to their brand of chip cutting the LUT count and going with a smaller part. But that might get you a savings or it might not. But having the option of buying the parts from another vendor will definitely get you a better price on *any* part you decide to use. Although they can be stupid about that too. I once was designing a Lucent part into my board. A vendor wanted to compete the Xilinx part on price and I gave them the parameters I used to select the part. When they came back with a price and I told them that was much higher than the Lucent part they asked me which one. I gave them the part number and they tried to tell me their competitive part was different from the one they had picked from my specs. Yes, the new part was cheaper than the Lucent part (a little), but it didn't have enough I/Os for my design and would not work! I tried to explain it to them and they refused to believe that their part was not equivalent. Talk about stupid!!!Article: 112327
I forgot to mention that much like buying a car, you should *never*, *ever* pay list price for FPGAs in any real quantity. Even if it is only 1000 a year, you can likely get 20% to 50% off of distributor list just by asking for it. You can get closer to 50% if you tell them a target price and that you are shopping it around to the different FPGA makers.Article: 112328
Does anynone know where can I find VHDL models for DDR modules? I have an XUP board and I want to run some simulations before downloading my design to the FPGA. I am not looking for a specific model. Any generic DDR model will do the job.Article: 112329
On Mon, 20 Nov 2006 09:48:37 -0800, "Joel Kolstad"
<JKolstad71HatesSpam@yahoo.com> wrote:
><pbdelete@spamnuke.ludd.luthdelete.se.invalid> wrote in message
>news:4560c4d3$0$486$cc7c7865@news.luth.se...
>> I heard an interesting comment once, students are not to be trusted with
>> untyped languages because they can't handle it. STILL same persons are
>> expected to handle advanced math with pen & paper..
>
>...and the computer-algebra system running on their calculators!
>
>I hope that the "students are not to be trusted with untyped languages" idea
>is universal; I'd be shocked if there weren't universities where, e.g., Python
>isn't being used on a regular basis. (If John Larkin wasn't already quite so
>fond of PowerBasic I'd suggest he'd probably really like Python...)
>
>
I like the PB Dos version because it can directly access hardware. I
can do INs and OUTs, and dimension an integer array *at* an address
that just happens to be a VME crate or a PCI device. Under DOS or '98,
of course. Or drop into assembly anywhere I feel like:
' \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
' \\\\\\\\\\\\\\\\\\\\ IN16 \\\\\\\\\\\\\\\\\\\\\
' \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
SUB IN16(PORT, DTA)
' READ A 16-BIT PORT
' PORT IS PORT ADDRESS
' DTA IS RETURNED DATA
LOCAL P, D ' WE MAKE LOCAL COPIES OF PARAMETERS
' TO MAKE ASM LINKAGES EASY.
P = PORT ' RECOVER CALLER'S PORT ADDRESS
ASM MOV DX, P ; GET PORT ADDRESS IN DX
ASM IN AX, DX ; READ PORT DATA INTO AX
ASM MOV D, AX ; POKE DATA INTO BASIC VARIABLE
DTA = D ' AND RETURN HIS DATA
END SUB
' SEARCH THE PCI BUS FOR THE TUNDRA CHIP
ASM MOV AH, &HB1 ; THIS BLOCK OF ASM CODE LOCATES THE
ASM MOV AL, &H02 ; TUNDRA UNIVERSE CHIP VIA THE VENDOR
ASM MOV CX, &H00 ; AND DEVICE ID. THEN IT RETURNS THE
ASM MOV DX, &H10E3 ; BUS NUMBER AND THE FUNCTION NUMBER
ASM MOV SI, &H00 ;
ASM INT &H1A ;
ASM MOV RECODE?, AH ; RETURNED STS, 0 = SUCCESS
ASM MOV BNUM?, BH ; PCI BUS NUMBER
ASM MOV FUNN?, BL ; DEV/FUNCTION NUMBER
IF RECODE? THEN ' DO WE HAVE A CHIP?
E$ = "TUNDRA CHIP NOT FOUND"
GOTO FATAL
END IF
' NOW USE A CONFIG SPACE WRITE TO RELOCATE THE TUNDRA
ASM MOV AH, &HB1 ; SUBFUN CODE = B102, WRITE CONFIG LW
ASM MOV AL, &H0D ;
ASM MOV BH, BNUM? ; BUS # FROM ABOVE
ASM MOV BL, FUNN? ; AND DEV/FUN FOR TUNDRA
ASM MOV DI, &H10 ; OFFSET TO PCI_BSO BASE ADD REG
ASM DB &H66 ; USE 32-BIT OPCODE PREAMBLE
ASM MOV CX, TUNLOC ; TO LOAD ECX WITH 32-BIT ADDRESS
ASM INT &H1A ; THEN RELOCATE TUNDRA THERE!
John
Article: 112330"gen_vlsi" <jesuraj.vinoth@gmail.com> wrote in message news:1164004615.735540.80450@h48g2000cwc.googlegroups.com... > Hi . > > Can anyone throw some light on false path and how to determine it > during synthesis. > See: http://www.ht-lab.com/misc/false_path.html This is quite a simple example but you can see that the data can only "flow" from xy1_s to xa2_s and from xa1_s to xy2_s. This means that the path through both multipliers is false. If the tpd of the multiplier is 100ns and the adder 10ns then your P&R tool might give you a total tpd of 200ns rather than 110ns. Finding these path is normally very time consuming and the way to tackle it is to only focus on the most negative slag path and work your way through the schematic and RTL. There are also tools that find these path automatically (e.g. Focus from Fishtail) but they are more for ASIC's than for FPGA's although I know that Focus also supports FPGA's, You might also want to google for Static and Dynamic sensitised paths, Hans www.ht-lab.comArticle: 112331
Does anynone know where can I find VHDL models for DDR-I SDRAM modules? I have an XUP board and I want to run some simulations before downloading my design to the FPGA. I am not looking for a specific model. Any generic DDR-I SDRAM model will do the job.Article: 112332
Hi,
I have a problem in uploading an .mcs file from the Spartan 3 Starter
Kit reference designs to the flash prom.
Specifically it is the design "Micro Blaze Master System" from
www.xilinx.com/products/boards/DO-SPAR3-DK/reference_designs.htm
I use Impact from the ISE WebPack vers. 8.1 and follow the standard
prescription for uploading .mcs files which - for example - always works
with the factory default .mcs or the .mcs I produced from own designs.
Concretely I assign the chosen .mcs file to the flash prom with Impact,
select the prom type xcf02s and then execute "program" with "verify"
selected.
But in the case mentioned above ("Master System") this gives me an error
in the verification phase after the upload. The error is accompanied by
a message "non contiguous address" (or the like).
What could be the reason for this ? Hardware fault ? Incompatibility
with newer Impact ? Wrong procedure on my side ?
To check for hardware problems I tried "blank" with "verify empty" on
the prom with Impact, this went through without error.
I would be very happy if someone could help me resolve this problem, so
that I can test all features of the board with this example design.
Greetings
Jürgen
--
Jürgen Böhm www.aviduratas.de
"At a time when so many scholars in the world are calculating, is it not
desirable that some, who can, dream ?" R. Thom
Article: 112333> Does anynone know where can I find VHDL models for DDR modules? Check out www.micron.com /MikhailArticle: 112334
John Larkin wrote: > On Sun, 19 Nov 2006 20:27:06 +0100, "petrus bitbyter" > <pieterkraltlaatditweg@enditookhccnet.nl> wrote: > >> >> >> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> schreef in >> bericht news:1ejvl2d3j9tj96emac307rtjfr2l4o40q1@4ax.com... >>> On Sun, 19 Nov 2006 00:24:34 GMT, PeteS <peter.smith8380@ntlworld.com> >>> wrote: >>> >>>> John Larkin wrote: >>>>> On Sat, 18 Nov 2006 23:23:30 GMT, PeteS <peter.smith8380@ntlworld.com> >>>>> wrote: >>>>> >>>>>> When I do pure hardware I do not have to try and figure out what the >>>>>> hell was done to implement my statements. >>>>>> >>>>>> This was a major issue on a design I did about 4 years ago where I >>>>>> interfaced an upstream bus to the busses on 6 devices (with a lot of >>>>>> other stuff) and the synthesis / PAR etc kept optimising away certain >>>>>> things that were there to maintain the timing. The response I got was >>>>>> 'well, use pure synchronous design' but in this case it was simply not >>>>>> possible (am issue I am sure you'll understand). >>>>> Yup, this *is* the real world. We recently had to do a clock-edge >>>>> deglitcher, using delay elements. It couldn't be synchronous, because >>>>> we were, well, deglitching the clock! Ditto stuff like charge-pump >>>>> phase detectors, where you really need exactly what you need, delays >>>>> and all. >>>>> >>>>> >>>>>> I once deliberately did a DeMorgan transform by hand because I did nto >>>>>> trust the tool to do it right. (Code available on request ;) ) >>>>>> >>>>>> Cheers >>>>>> >>>>>> PeteS >>>>> >>>>> One thing you can do is add a pulldown to a pin (or ground it) and >>>>> call that signal ZERO or something. Then just OR it with things to >>>>> create new, buffered, delayed things. If you need more, run it through >>>>> a shift register and create ZERO1, ZERO2, etc. The compiler can't >>>>> optimize them out! >>>>> >>>>> So the FPGA software people ought to provide us an irreducible ZERO >>>>> without wasting a pin, or a buffer that stays a buffer always. >>>>> >>>>> So, is there a block of logic so complex that the compiler can't >>>>> figure out that it indeed will always output a zero? Maybe the MSB of >>>>> a thousand-year counter, but that wastes flops. Maybe some small but >>>>> clever state machine that always makes zero but is too tricky to be >>>>> optimized? >>>>> >>>>> John >>>>> >>>> As noted, I once did a DeMorgan transform by hand (simple one too) and >>>> it materially changed the compiled output. (For those who understand the >>>> transform, don't get upset at the comments; they were there for people >>>> who _didn't_). >>>> >>>> Here it is: >>>> >>>> ****************************** >>>> >>>> else begin >>>> cs0 <= cs_l; // make a direct copy of the cs signal >>>> cs1 <= (cs0 | cs_l); // Note - this uses a DeMorgan transform >>>> // the formula really is this : cs1 <= !(!cs_l & !cs0) >>>> // rather than cs1 <= (!cs_l & !cs0) >>>> // Note the extra output inversion, which renders an >>>> // inversion unnecessary >>>> // DeMorgan's theorem is this >>>> // <y = !a & !b> === <!y = a | b> >>>> // i.e. invert all signals and change and to or and vice >>>> // versa. Note this works only on basic functions >>>> // ( &, |, ! ) (AND, OR, INVERT) >>>> // for a valid select, we need two consecutive samples of >>>> // cs_l low. Latch a low, then look at the latch and the >>>> // signal on the pin. If both are low, cs1 goes low. If >>>> // either are high (glitch, runt pulse) then cs1 stays high >>>> // We trigger on internal cs (cs1) going low >>>> // Why did I use it? Because it requires no inverters and >>>> // therefore saves me a gate delay by simply using a LUT >>>> // without inversion >>>> // >>>> // Of course, the tools *might* do this, but I can't >>>> // guarantee it, so I'll *****ing so it myself. >>>> end >>>> ***************************************** >>>> >>>> Cheers >>>> >>>> PeteS >>> They should back off this religious devotion to fully synchronous >>> logic and give us a couple of dozen programmable true delay elements, >>> scattered about the chip. But they won't because it's not politically >>> correct, and because they figure that we're so dumb that we'd get into >>> trouble using them. >>> >>> >>> John >>> >> Well, synchronous design is easier and more understandable then >> asynchronous. So the "specialists" tell the world synchronous design is the >> only way rather then confess they are unable to make reliable asynchronous >> ones. And let's be honest. A lot of old asynchronous designs are real >> nightmares of critical race conditions, ad hoc inserted RC delays, glitches >> and tricks. Good asynchronous engineering is rare and was rare even in the >> days synchronous design was not yet invented. (Practised may be the better >> word.) > > There are some people doing serious (cpu-scale) async logic, but > that's pretty thin-air stuff. What I meant was that, even in a > properly synchronous design, there are times where a real, analog > delay is a useful design element, and it sometimes can save a full > clock worth of time... not all data paths need a full clock to settle. > Plus, it would be nice to be able to dynamically tune data:clock > relationships and such. I have one architecture that we use a lot that > simply must have a real, unclocked one-shot (among other things, it > stops and resets the clock oscillator!) so we have to go off-chip to a > discrete r-c. > > >> I ever was asked to "debug" a time critical circuit. Looking at the >> asynchronous circuit which failed only once a week or so and reading the >> full page of explanations about the inner workings I discarded the whole >> design, doubled the clock frequency and made a rock solid synchronous >> circuit. They were almost disappointed it was that "easÿ". I could have made >> disciples for "synchronous only" but I'm not a true believer myself. >> Times they are a changing. I heard rumours asynchronous design has a revival >> as it can be used to build faster circuits. There should be special software >> for it, meant to design processors and the like. It's those software that >> makes me shiver. When the first micros hit the market, an engineer >> complained that those programmers used lots of extra space. He would have >> been fired by using only one percent of that number in extra gates. (Nothing >> to do with old uncle Billy :) Things did not grow better ever since but the >> real bad development is the habit of those programmers to think and make >> decisions for me. I really hate that. Almost all of these programmers have a >> theoretical background in "software engineering". Ever visited such a >> college with lots of computers, tens of masters and hundreds of students and >> no one could handle a soldering iron. There was none in the whole place. > > I toured the Cornell EE department recently. 95% of the screens are on > PC's, maybe 5% are oscilloscopes. No soldering irons in sight, just > those drecky white plastic breadboards. Tulane, my alma mater, used > Katrina as an excuse for eliminating the EE department entirely. I > guess those labs are too expensive, compared to one TA teaching 400 > kids art history in a lecture hall, all at once. > >> An >> assistant brought his own one from home when he needs to repair a cable. >> None of those "engineers" ever wrote bugfree software, but expect hardware >> designs to be it. Nevertheless, if something goes wrong, it's inevitable a >> hardware failure. I ever had technicians to exchange hardware seven times >> before they stopped to deny it to be a bug in the software. Another time one >> of my collegues disassembled a floppy driver to prove it did not met the >> drive specifications. (It could not format a floppy and they insisted we >> used the wrong brand of floppy although we tried every brand we could lay >> our hands on.) They complained about the disassembly rather then admit their >> own failure. >> > > Yeah, there is a lot of ad-hoc async stuff around, full of 555's and > one-shots and race conditions and such. Disciplined sync design should > be the starting point from which to cheat. > > >> Well, maybe we're doomed. Maybe I'm going to write software. What's worse? >> :) > > > I'm stuck, all this month at least, rewriting a diastrous, 14,000 line > mess (68K assembly) that took over a man-year of work to make this > bad. Programming is OK, but after a couple of weeks of it I get > depressed... too much like bookkeeping. I can design hardware forever. > > Gotta do the ghastly serial DAC driver next. The Xilinx bit-bang > serial config thing worked like a charm, even blinking an LED during > the loop. > > John > > Well, I have just done a SPI master/slave block *completely synchronously*. If you ever need one, email me (works up to a 4MHz at least, which is beyond the spec of the A-Ds I am controlling). Works like a charm (I implemented the Motorola style 4 wire interface). I wasn't completely clear; I prefer synchronous design *where I can* There are times I can not. Then there are places it is obviously proper, but times it is not. In an upgraded (being upgraded) design, I have removed a lot of parts in favour of an FPGA, and those parts must be duplicated from the perspective of the processor. As the interface was previously asynchronous, and changing interfaces is a royal pain, I have to implement an asynchronous bus. In such cases, I use delay tricks to make sure I get the timing I know will work with the measured (and documented) timings from the processor. I could, of course, do synchronous design internally, *provided I run the clock fast enough*, but that uses precious power in a handheld unit and i can't live with it *simply for a bus interface clock* when it's perfectly possible to do it asynchronously. I handle the necessary synchronisation to the internal blocks with 2 FF resynchronisers. In this case, I would need to run the internal clocks at least at 50MHz which would blow my power budget. That brings up a major advantage of asynchronous design; power consumption. When my device sleeps, I *stop the clocks completely* except for the processor (which stops it's own clocks) and then restart things properly later; but the wakeup sequencers must be completely asynchronous. So is synchronous design better? Depends on the question being asked. Cheers PeteSArticle: 112335
lecroy7200@chek.com wrote: > I can't seem to find a document that calls out the XY locations for the > IDELAYCTRL. Where is this information found? > > When I don't use the LOC, the report for P&R says it has used 100% of > the IDELAYCTRLs. No surprize. When I look at the FPGA editor I would > expext to see all of them listed but instead I only see a small portion > of them. Why? > > It appears that if I include an IDELAY that there is some sort of > requirement on where the IDELAYCTRL is located. Currently I don't use > the LOC, let the tool P&R then use the FPGA editor to see where it > placed it. Then I use the LOC. What a pain. There must be a simpler > way. I tell the tools where the IDELAY is to be used, why is it that > the tools can't place the controller automatically? > > If I select the wrong location for the IDELAYCTRL, the tool does not > flag an error, the design just fails to work. You would think it would > be smart enough to know. > As long as you run all the idelays on the same 200 MHz reference clock, and that reference clock runs continuously, you shouldn't need to separately reference the idelayctrl's, which means you can just put one at the top level of your design and run the idly_rdy to all instances of your idelays. If there is only one idelayctrl instantiated in your design, then the PAR tools automatically replicate it and you don't need to put any RLOCs on it. I believe the replication replicates it into all sites, and then map later trims out any that are in regions where there are no idelays used and the rdy pin is not used. If the rdy pin is used, the software instantiates an AND gate to combine all the RDY's into one signal, so if RDY is used, all the idelaysctrls remain in the circuit. This will lead to higher power consumption, but otherwise doesn't adversely affect the design. Xilinx does recommend using LOCs and explicitly placing these, but like you, I found that highly inconvenient. The only place I think you can get the locations is off FPGA editor, and those change depending on the particular device. Unless you are either a) concerned about every bit of power consumption, b) using the rdy's differently for different banks and can't live with waiting till all the idelayctrls come on line, or c) are doing something where you have different reference clocks (why would you do this?) or different resets for the idelayctrls, then I think the added power consumption and the big and gate are a very small price to pay for the simplicity of the un LOC'd instancing.Article: 112336
Ray Andraka wrote: > John Larkin wrote: > > >> >> They should back off this religious devotion to fully synchronous >> logic and give us a couple of dozen programmable true delay elements, >> scattered about the chip. But they won't because it's not politically >> correct, and because they figure that we're so dumb that we'd get into >> trouble using them. >> >> >> John >> > > Virtex4 has them. They are the idelay elements, which give you 64 steps > of delay with 75ps granularity. That's great, but for those of us using lower power [and on a lower budget ;) ] devices, I could wish for the tools to obey my requirements, but that would be a 'vendor specific solution' unless I could get Verilog / VHDL changed to have a keyword where the synthesis / PAR tools would understand that 'this is not to be optimised in any way' on a perhaps module basis, rather than on a global basis (WYSIWYG comes to mind). I've even gone to the extent of specifically instantiating primitives, and PAR *still* optimises them out, even though there's plenty of room for the logic, and I really wanted to do it that way for various reasons. I do not want the tools to try and think for me; software that tries to be that smart only succeeds in being dumb. I have written a *lot* of software, and I learned that lesson the hard way. As John already noted, the fervency around synchronous design is almost religious. As I note in another post, it's preferable *most of the time*, but there are times it actually prevents me from doing things properly. One could hope the FPGA vendors and tool vendors might listen to experienced pure hardware designers on this. Cheers PeteSArticle: 112337
petrus bitbyter wrote: > "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> schreef in > bericht news:1ejvl2d3j9tj96emac307rtjfr2l4o40q1@4ax.com... >> On Sun, 19 Nov 2006 00:24:34 GMT, PeteS <peter.smith8380@ntlworld.com> >> wrote: >> >>> John Larkin wrote: >>>> On Sat, 18 Nov 2006 23:23:30 GMT, PeteS <peter.smith8380@ntlworld.com> >>>> wrote: >>>> >>>>> When I do pure hardware I do not have to try and figure out what the >>>>> hell was done to implement my statements. >>>>> >>>>> This was a major issue on a design I did about 4 years ago where I >>>>> interfaced an upstream bus to the busses on 6 devices (with a lot of >>>>> other stuff) and the synthesis / PAR etc kept optimising away certain >>>>> things that were there to maintain the timing. The response I got was >>>>> 'well, use pure synchronous design' but in this case it was simply not >>>>> possible (am issue I am sure you'll understand). >>>> Yup, this *is* the real world. We recently had to do a clock-edge >>>> deglitcher, using delay elements. It couldn't be synchronous, because >>>> we were, well, deglitching the clock! Ditto stuff like charge-pump >>>> phase detectors, where you really need exactly what you need, delays >>>> and all. >>>> >>>> >>>>> I once deliberately did a DeMorgan transform by hand because I did nto >>>>> trust the tool to do it right. (Code available on request ;) ) >>>>> >>>>> Cheers >>>>> >>>>> PeteS >>>> >>>> One thing you can do is add a pulldown to a pin (or ground it) and >>>> call that signal ZERO or something. Then just OR it with things to >>>> create new, buffered, delayed things. If you need more, run it through >>>> a shift register and create ZERO1, ZERO2, etc. The compiler can't >>>> optimize them out! >>>> >>>> So the FPGA software people ought to provide us an irreducible ZERO >>>> without wasting a pin, or a buffer that stays a buffer always. >>>> >>>> So, is there a block of logic so complex that the compiler can't >>>> figure out that it indeed will always output a zero? Maybe the MSB of >>>> a thousand-year counter, but that wastes flops. Maybe some small but >>>> clever state machine that always makes zero but is too tricky to be >>>> optimized? >>>> >>>> John >>>> >>> As noted, I once did a DeMorgan transform by hand (simple one too) and >>> it materially changed the compiled output. (For those who understand the >>> transform, don't get upset at the comments; they were there for people >>> who _didn't_). >>> >>> Here it is: >>> >>> ****************************** >>> >>> else begin >>> cs0 <= cs_l; // make a direct copy of the cs signal >>> cs1 <= (cs0 | cs_l); // Note - this uses a DeMorgan transform >>> // the formula really is this : cs1 <= !(!cs_l & !cs0) >>> // rather than cs1 <= (!cs_l & !cs0) >>> // Note the extra output inversion, which renders an >>> // inversion unnecessary >>> // DeMorgan's theorem is this >>> // <y = !a & !b> === <!y = a | b> >>> // i.e. invert all signals and change and to or and vice >>> // versa. Note this works only on basic functions >>> // ( &, |, ! ) (AND, OR, INVERT) >>> // for a valid select, we need two consecutive samples of >>> // cs_l low. Latch a low, then look at the latch and the >>> // signal on the pin. If both are low, cs1 goes low. If >>> // either are high (glitch, runt pulse) then cs1 stays high >>> // We trigger on internal cs (cs1) going low >>> // Why did I use it? Because it requires no inverters and >>> // therefore saves me a gate delay by simply using a LUT >>> // without inversion >>> // >>> // Of course, the tools *might* do this, but I can't >>> // guarantee it, so I'll *****ing so it myself. >>> end >>> ***************************************** >>> >>> Cheers >>> >>> PeteS >> They should back off this religious devotion to fully synchronous >> logic and give us a couple of dozen programmable true delay elements, >> scattered about the chip. But they won't because it's not politically >> correct, and because they figure that we're so dumb that we'd get into >> trouble using them. >> >> >> John >> > > Well, synchronous design is easier and more understandable then > asynchronous. So the "specialists" tell the world synchronous design is the > only way rather then confess they are unable to make reliable asynchronous > ones. And let's be honest. A lot of old asynchronous designs are real > nightmares of critical race conditions, ad hoc inserted RC delays, glitches > and tricks. Good asynchronous engineering is rare and was rare even in the > days synchronous design was not yet invented. (Practised may be the better > word.) > I ever was asked to "debug" a time critical circuit. Looking at the > asynchronous circuit which failed only once a week or so and reading the > full page of explanations about the inner workings I discarded the whole > design, doubled the clock frequency and made a rock solid synchronous > circuit. They were almost disappointed it was that "easÿ". I could have made > disciples for "synchronous only" but I'm not a true believer myself. > Times they are a changing. I heard rumours asynchronous design has a revival > as it can be used to build faster circuits. There should be special software > for it, meant to design processors and the like. It's those software that > makes me shiver. When the first micros hit the market, an engineer > complained that those programmers used lots of extra space. He would have > been fired by using only one percent of that number in extra gates. (Nothing > to do with old uncle Billy :) Things did not grow better ever since but the > real bad development is the habit of those programmers to think and make > decisions for me. I really hate that. Almost all of these programmers have a > theoretical background in "software engineering". Ever visited such a > college with lots of computers, tens of masters and hundreds of students and > no one could handle a soldering iron. There was none in the whole place. An > assistant brought his own one from home when he needs to repair a cable. > None of those "engineers" ever wrote bugfree software, but expect hardware > designs to be it. Nevertheless, if something goes wrong, it's inevitable a > hardware failure. I ever had technicians to exchange hardware seven times > before they stopped to deny it to be a bug in the software. Another time one > of my collegues disassembled a floppy driver to prove it did not met the > drive specifications. (It could not format a floppy and they insisted we > used the wrong brand of floppy although we tried every brand we could lay > our hands on.) They complained about the disassembly rather then admit their > own failure. > > Well, maybe we're doomed. Maybe I'm going to write software. What's worse? > :) > > petrus bitbyter > > _Me_ going back to software! Muahahaha Cheers PeteSArticle: 112338
Hi Bob, Please see if the user guide available at http://www.altera.com/literature/ug/ug_altpll_reconfig.pdf answers your questions. If it does not do sen me email. Hope this helps, Subroto Datta Altera Corp. On Nov 20, 5:46 am, Bob <rjmy...@raytheon.com> wrote: > For some reason, I'm not getting how to create the various > .mif files to initialize enhanced PLLs with Quartus II. > I'm trying to target a Stratix II device. The situation that > I'm in will require me to reconfigure the PLL's divisors > dependent upon the state of an input pin on the FPGA. > > Anyone got a step-by-step set of instructions that cleary > describe how to do this?Article: 112339
Hi Bob, also check out http://www.altera.com/literature/an/an367.pdf which will have more Stratix II specific information on this topic. Hope this helps, Subroto Datta Altera Corp. On Nov 20, 3:11 pm, "Subroto Datta" <sda...@altera.com> wrote: > Hi Bob, > Please see if the user guide available athttp://www.altera.com/literature/ug/ug_altpll_reconfig.pdf > answers your questions. If it does not do sen me email. > > Hope this helps, > Subroto Datta > Altera Corp. > > On Nov 20, 5:46 am, Bob <rjmy...@raytheon.com> wrote: > > > > > For some reason, I'm not getting how to create the various > > .mif files to initialize enhanced PLLs with Quartus II. > > I'm trying to target a Stratix II device. The situation that > > I'm in will require me to reconfigure the PLL's divisors > > dependent upon the state of an input pin on the FPGA. > > > Anyone got a step-by-step set of instructions that cleary > > describe how to do this?- Hide quoted text -- Show quoted text -Article: 112340
JJ wrote: >Every transistor counts whether it is a logic pull down (enhancemenet) >or load (depletion). or clocked pass gate or even any capacitors which >are usually free in area, its always distinct mos gate area. A >depletion transitor is usually used as a constant current source rather >than resistor, but as a resistor if the gate has fixed voltage. >Typically for all static logic I would expect 3 logic and 1 load device >on avg, but in this case most logic was precharged and conditionally >discharged. Only the register flops had to be static. > >Since it had a 12v supply, it may have not had any depletion device >loads, using long thin enhacment t's s as loads, mucho area and power >and poor speed. The 8085, Z80 definitely had depletion and hidden >poly-diff contacts to simplify everthing. > >I did have the schematic for the datapath area and thats about 30% of >the chip. IIRC maybe 8-10 registers included umdocumented, each was >probably a 4t asymetric cross couple with an extra t to read and and t >for write. An ALU bit slice is probably 20-30 t's so 1 datapath >bitslice is probably <100 devices so <1000 for the whole math area.. > >Remember that t logic (see Mead Conway) can do alot for a few devices. >2e1d devices makes a 2 input nor or nand or poor mans xor and the ALU >used only a few per bit. The carry was a precharged manchester pass >gate with conditional discharge, the P,G terma probably reused a mux >box function generator (a bit like a LUT) that also did the logic >operations. > >Also the whole thing was state sequential, no pipelining so many cycles >used to do trivial operations. The entire schematc could have easily >been drawn on 1 large sheet of paper if need be. > > > Even as a gate-level schematic it would be a pretty busy sheet of paper! I hope the OP is not going to go through with this project. There is Seymour Cray's first computer at the Computer History Museum, a big box with hundreds of small boards he etched by hand in his garage. Of course, he got to sell the thing to the Navy when he finished it. The OP is going to go through the same level of effort, but he won't make a dime on it. I'm reminded of the guy in Germany, I think, who built a digital clock using vacuum tubes for all the amplifying elements. Even using some very tricky designs with multi-grid tubes, it was a monster with over 100 tubes. Jon JonArticle: 112341
Neil Glenn Jacobson <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> writes: > Unfortunately, the drivers and iMPACT software for 64 bit platforms > will not be available until the next release of ISE due in Jan, 2007 If that includes 64-bit Linux, it's great news. :-)Article: 112342
kempaj@yahoo.com wrote: > On Nov 17, 6:50 am, "Antti" <Antti.Luk...@xilant.com> wrote: > > I just cant belive it, its one of the most useful things for the FPGA > > SoC designs, and its just not there? I really doesnt have time or fun > > to reverse engineer the .SOF format only to be able write the data2sof > > utility for Altera. > > Antti, > > Others have commented on the general-purpose case, but since you made a > specfiic reference to processors its worth discussing the soft-CPU flow > for > placing your code/data into onchip ram. > > No, this wasn't forgotten. In fact, support for doing this has been > around about > as long as Nios I/Nios II have been (6+ years now?). There are even > several ways > to accomplish the task: > > - If you are building your Nios II software in the IDE, it will take > any coce/data linked into > an onchip memory peripheral and use the elf2hex command to create a hex > initialization > file. The onchip RAM RTL generated by SOPC Builder is written out to be > initialized this > way; if you compile your design w/o any software having been built, > memory will be left > un-initialized, while if you first compile your software and then > (re)compile in quartus, > the .hex file(s) are used to initialize the memories. > > If you turn on verbose command line output from the IDE (window -> > preferences -> nios II), > you'll see the precise commands fly by on the console for future > reference and command- > line use. > > - Although the IDE-based flow doesn't do this now, you can even update > your .sof > file very quickly with onchip ram contents without risk of triggering > an entire > re-compile. I cannot recall the exact syntax of the command but I > believe the compilation > step is the Quartus Assembler (quartus_asm) > > - The "small" example design that ships with Nios II uses the above > IDE-based > method to initialize onchip RAM and as I recall the design's readme and > other > literature discuss this. > > Note that there are exclusions to what I've said, specifically for the > types of > onchip ram (m-ram blocks in Stratix, Stratix II) that cannot be > initialized until > runtime. The wizard to create an onchip ram in SOPC Builder allows you > to > choose which type of ram block will be used, if you desire, to ensure > that you > can pre-initialize contents if that is what you need to do. > > Jesse Kempa > Altera Corp. > jkempa --at-- altera --dot-- com This is all well and good, but even with smart compilation turned on, things don't work quite as well as they should. I'm designing my own CPU core, so I'm not using NIOS, but I still need to be able to update BRAM's with new program code. I've already worked around (sort of) the fact that for some reason, Quartus won't properly update a BRAM from a .hex file. (.hex files work fine for compilation, but not a mif/hex update. So, I bring my .hex file into Quartus, and save it as a .mif file. This is annoying, since I can no longer automate the whole build process. At some point, when I get irritated enough, I'll write a program that converts hex to mif correctly, but I haven't had the time for much extra programming lately. However, the MORE irritating problem I've run into is that if I repeat the mif/hex update process a second time, changing only the .mif file, Quartus launches into a full recompile anyway. This is a bit frustrating, since the "hardware" is stable at this point. I just need to test software. Perhaps I've missed something, but I've yet to find a way to avoid the full recompile on the second update. Maybe this works correctly in the NIOS flow, but I don't have that tool available. I did try the NIOS eval, though, and I didn't see any new tools in it that looked like they would solve my problem.Article: 112343
Ray Andraka <ray@andraka.com> writes: > Virtex4 has them. They are the idelay elements, which give you 64 > steps of delay with 75ps granularity. One step closer to a synthesizeable VHDL "wait for 2 ns" statement! Not that I think it's a good idea, but newbies are always asking for it. :-)Article: 112344
Hello, Does anyone know if XFFT_V3_1 Verilog (not VHDL) module (normally found in C:\Modeltech_xe_starter\xilinx\verilog\XilinxCoreLib_ver) exists? It was not shipped with ISE7.1i (I have noticed a few people in newsgroups asking similar question), I got the update from Xilinx site but still no luck. If you know, can you please point me to where to -download it -or compress and email it to me at vmykhayl@ee.ryerson.ca. Regards, Vitaliy PS. The error message: # vsim -L xilinxcorelib_ver -L unisims_ver -lib work -t 1ps design_top_tb_tf glbl # Loading work.design_top_tb_tf # Loading work.design_top # ** Warning: (vsim-3009) [TSCALE] - Module 'design_top' does not have a `timescale directive in effect, but previous modules do. # Region: /design_top_tb_tf/uut # Loading C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver.IBUFG # Loading C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver.DCM # Loading C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver.dcm_clock_divide_by_2 # Loading C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver.dcm_maximum_period_check # Loading C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver.dcm_clock_lost # Loading C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver.BUFG # Loading work.my_radix2_xfft1024 # ** Error: (vsim-3033) my_radix2_xfft1024.v(135): Instantiation of 'XFFT_V3_1' failed. The design unit was not found. # Region: /design_top_tb_tf/uut/U3 # Searched libraries: # C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/xilinxcorelib_ver # C:\Modeltech_xe_starter\win32xoem/../xilinx/verilog/unisims_ver # workArticle: 112345
Jon Elson wrote: Some people have way too much time on their hands!Article: 112346
PeteS wrote: > Ray Andraka wrote: > >> John Larkin wrote: >> >> >>> >>> They should back off this religious devotion to fully synchronous >>> logic and give us a couple of dozen programmable true delay elements, >>> scattered about the chip. But they won't because it's not politically >>> correct, and because they figure that we're so dumb that we'd get into >>> trouble using them. >>> >>> >>> John >>> >> >> Virtex4 has them. They are the idelay elements, which give you 64 >> steps of delay with 75ps granularity. > > > That's great, but for those of us using lower power [and on a lower > budget ;) ] devices, I could wish for the tools to obey my requirements, > but that would be a 'vendor specific solution' unless I could get > Verilog / VHDL changed to have a keyword where the synthesis / PAR tools > would understand that 'this is not to be optimised in any way' on a > perhaps module basis, rather than on a global basis (WYSIWYG comes to > mind). > > I've even gone to the extent of specifically instantiating primitives, > and PAR *still* optimises them out, even though there's plenty of room > for the logic, and I really wanted to do it that way for various > reasons. I do not want the tools to try and think for me; software that > tries to be that smart only succeeds in being dumb. I have written a > *lot* of software, and I learned that lesson the hard way. > > As John already noted, the fervency around synchronous design is almost > religious. As I note in another post, it's preferable *most of the > time*, but there are times it actually prevents me from doing things > properly. One could hope the FPGA vendors and tool vendors might listen > to experienced pure hardware designers on this. > > Cheers > > PeteS If you really feel the need for async design, it can be done with utmost care on an FPGA, but such a design has to take into account the routing delays. The tools do not support specifying the routing delays beyond that needed to satisy synchronous operation, and for a very good reason (I'll address that in a moment). You can keep the tools from optimizing out pieces you need through addition of keep attributes. You can also instantiate primitives, which the tools generally do not remove (but you need to be careful with simple inversions or buffers), or you can create routed macros with FPGA editor. The hooks are there for manually doing your async design, and I have used them on the rare occasion. It is tedious and error prone, but everything you need to do it is there. That said, the FPGAs and tools are targeted to the sync design audience, as that is the bread and butter of the industry. The analysis and design is far easier to get correct with synchronous design rules, and as a result the tools are far easier to design and use for those cases. Since the synchronous design domain represents the large majority of all digital design, and the tools for doing it are lower hanging fruit than what is required for async design, it is natural the FPGA vendors only target that market, and to not have any interest in the async market. The cost to entry is too high: tools are much harder to design and verify, there are many more gotchas that need to be covered and tested for, there is a potential for far more technical support needs, and on top of all that a market that is less than a percent of the total market. Why would any sane vendor even pursue that when there are so many other easier to obtain ways to make money?Article: 112347
Hi,
I am new to tcl and quartus. When I try to follow the tcl example on
page 2-2, Quartus II handbook, vol. 2, I cannot pass the second step,
i.e. fitter, see the following. At the same directory, GUI does pass
well. I don't know what is wrong. Can you help me out? Thank you very
much.
# quartus_fit filtref --part=EP1C12Q240C6 --fmax=80MHz --tsu=8ns
Info:
*******************************************************************
Info: Running Quartus II Fitter
Info: Version 6.0 Build 202 06/20/2006 Service Pack 1 SJ Web
Edition
Info: Copyright (C) 1991-2006 Altera Corporation. All rights
reserved.
Info: Your use of Altera Corporation's design tools, logic
functions
Info: and other software and tools, and its AMPP partner logic
Info: functions, and any output files any of the foregoing
Info: (including device programming or simulation files), and any
Info: associated documentation or information are expressly subject
Info: to the terms and conditions of the Altera Program License
Info: Subscription Agreement, Altera MegaCore Function License
Info: Agreement, or other applicable license agreement, including,
Info: without limitation, that your use is for the sole purpose of
Info: programming logic devices manufactured by Altera and sold by
Info: Altera or its authorized distributors. Please refer to the
Info: applicable agreement for further details.
Info: Processing started: Mon Nov 20 22:33:28 2006
Info: Command: quartus_fit filtref --part=EP1C12Q240C6 --fmax=80MHz
--tsu=8ns
Info: Selected device EP1C12Q240C6 for design "filtref"
Info: Fitter is performing a Standard Fit compilation using maximum
Fitter effort to optimize design performance
Error: Can't place node "clk" -- illegal location assignment PIN_G1
Error: Can't fit design in device
Error: Quartus II Fitter was unsuccessful. 2 errors, 0 warnings
Error: Processing ended: Mon Nov 20 22:33:30 2006
Error: Elapsed time: 00:00:02
child process exited abnormally
#
Article: 112348John Larkin wrote: > On Sat, 18 Nov 2006 17:58:50 GMT, PeteS <peter.smith8380@ntlworld.com> > wrote: > >>John Larkin wrote: >>> On Sat, 18 Nov 2006 11:30:03 GMT, PeteS <peter.smith8380@ntlworld.com> >>> wrote: >>> >>>> John Larkin wrote: >>>>> This is the thing I'm working on this month. It's a delay generator, >>>>> with an MC68332 uP on the back side that manages things. One of my >>>>> guys quit, leaving behind about 14 klines of nasty, buggy code, so I >>>>> thought it over for about 18 seconds and tossed it and started over >>>>> from scratch. I'm workin with another guy who is re-doing the nasty, >>>>> buggy FPGA design, ditto. He says bad things about the V8.2/SP3 Xilinx >>>>> WebPack software. >>>>> >>>>> The application program is in flash, soldered down, and we're going to >>>>> include a flash boot-block thing that lets you reflash the app code >>>>> through the serial or ethernet ports, to upgrade the firmware. That's >>>>> sort of mind-boggling, since the flash which holds this boot program >>>>> disappears from the uP bus while it's being erased or programmed. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>> That's an interesting non-ortho arrangement :) >>>> >>>> On Webpack 8.2 SP3, I am afraid he's right. There have been some >>>> rumblings on comp.arch.fpga about it recently, and I 'upgraded' to it >>>> for my latest design, and then it would not process 3 previous designs, >>>> although those have no errors I can see. Xilinx claimed it had >>>> 'tightened up' certain things, but it caused me some grief because >>>> those designs are the basis for a number of things where the FPGA code >>>> is designed to in-system upgradeable should some new feature be >>>> requested. I eventually re-installed (from an old full download) 7.1 >>>> for those projects. >>> >>> Yeah, I wish people would stop breaking things, and stay absolutely >>> backwards-compatible to existing designs. FPGA were supposed to make >>> hardware design easier, and then they sent in an army of programmers >>> to replace hardware problems with software nightmares. >>> >>> The *service pack* is a 300 megabyte download. >>> >>>> I've done the reprogrammable flash thing myself and I definitely concur >>>> it _can_ get a little hairy. >>>> >>>> Wish you the best of luck getting the design fully operational. What >>>> are the specs? >>> >>> Here it is. Fortunately, the hardware is in good shape, so all we have >>> to do is pound the firmware and fpga into submission. Soon. >>> >>> http://www.highlandtechnology.com/DSS/T560DS.html >>> >>> >>> John >>> >>Nice specs indeed. >> >>If I had the money, I'd want one ;) >> >>Cheers >> >>PeteS > > But hey, this is a revelation: > > Hardware design has always been comforting because it is direct, > simple, visible, wysiwyg, physical, and generally reliable. The tools, > oscilloscopes and such, are approachable and dependable. I can use a > 30-year old tube-type TEK oscilloscope to debug the most modern analog > or digital circuits, without downloading and installing service packs. > > Software is abstract, indirect, bizarre, and unreliable. The tools are > buggy, bloated, always changing, unpredictable, pig slow, and seldom > backwards-compatible. I can't use current-gen tools to edit a 2-year > old FPGA design, and I'm lucky if I can somehow still find and run the > older tools. > > So, FPFAs, VHDL, and the associated software tools are the trojan > horse that's finally letting the software people get revenge, finally > allowing them to force us hardware designers depend on (and endlessly > pay for) their bizantine and unreliable methodologies, to trap us in > the gotta-upgrade-but-every-generation-has-more-new-bugs loop. > > And the new Windows-based scopes and logic analyzers, of course... > same idea. > > John Come to the open source side John. -- JosephKK Gegen dummheit kampfen die Gotter Selbst, vergebens.  --SchillerArticle: 112349
Spehro Pefhany wrote: > On Sat, 18 Nov 2006 12:24:16 -0800, the renowned John Larkin > <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >>But hey, this is a revelation: >> >>Hardware design has always been comforting because it is direct, >>simple, visible, wysiwyg, physical, and generally reliable. The tools, >>oscilloscopes and such, are approachable and dependable. I can use a >>30-year old tube-type TEK oscilloscope to debug the most modern analog >>or digital circuits, without downloading and installing service packs. >> >>Software is abstract, indirect, bizarre, and unreliable. The tools are >>buggy, bloated, always changing, unpredictable, pig slow, and seldom >>backwards-compatible. I can't use current-gen tools to edit a 2-year >>old FPGA design, and I'm lucky if I can somehow still find and run the >>older tools. >> >>So, FPFAs, VHDL, and the associated software tools are the trojan >>horse that's finally letting the software people get revenge, finally >>allowing them to force us hardware designers depend on (and endlessly >>pay for) their bizantine and unreliable methodologies, to trap us in >>the gotta-upgrade-but-every-generation-has-more-new-bugs loop. >> >>And the new Windows-based scopes and logic analyzers, of course... >>same idea. >> >>John > > How about programs such as Solidworks that are only one-way upward > compatible. I.e. you can open a part or assembly file created in SW > 2005 with SW 2006 but once you save it in 2006 it cannot ever be > opened again in 2005 (or 2004, or 2003 etc.). Thus forcing everyone to > upgrade... > > > Best regards, > Spehro Pefhany Do you not have a disciplined backup approach? You can always get a 2005 or 2004 model and the SW to work it with a disciplined backup framework. -- JosephKK Gegen dummheit kampfen die Gotter Selbst, vergebens.  --Schiller
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