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
"Clark Pope" <cepope@mindspring.com> wrote in message news:<a2t2bs$qso$1@slb5.atl.mindspring.net>... > I am having the same problem, except I am using a VirtexII part. > > If I implement a single rate FIR it simulates and works great. As soon as I > implement a filter with 2 cycles/output it all goes to trash. (Still > simulates fine.) > > I have sent my stuff into Xilinx but they claim(so far) that their are no > known defects with coregen halfband filters. > > Let me know if you get resolution, I'll do the same. > > -Clark Clark, it is very intersting. I wonder if you have the same problem as I do. Do your outputs get inverted? -- YuryArticle: 38851
Paul wrote:
>
> Just a minor comment about Quartus and Leonardo (2001_1d) on win2k
>
> I did a few benchmarks of the 6502 core at www.free-ip.com
>
> Using native Quartus the synthesised design was 2000+ LE at 29MHz, using
> Leonardo instead with Altera's place and Route brought this to 998LE and
> 42MHz
>
I had similar similar experiences with Altera's in-house
synthesis tool.
I synthesized my synthesizable Verilog-based PCI IP core + A really
simple user module which uses about 755 Slices in Spartan-II.
755 Slices is about roughly 1,500 LEs in Altera devices like FLEX10KE.
When I synthesized the exact same code in LeonardoSpectrum-Altera Ver.
2001_1a_28_OEM_Altera targeting FLEX10KE-100K-1, I got about roughly
1600 LEs.
For FLEX10KE-100K typical gate part, that's about 30% of the chip.
However, when I synthesized the exact same design in Quartus II 1.1 Web
Edition's Altera's in-house synthesis tool, I got about 2,500 LEs, and
that's about 50% of the chip.
However, Altera's synthesis tool fared somewhat better in terms of fmax
(50MHz for LeonardoSpectrum vs. 58MHz in-house) and had less Tsu
violations.
> I've done other benchmarks of substantial cores with similar results (well
> except for the 8051 synthesisable core which always crashes Quartus no
> matter what)
>
> I've found Leonardo to have a few rough edges but only one crash. Quartus 2
> on the other hand is still as reliable as a custard castle in a sandstorm.
>
> I love the way it crashes midway through updating your design files to trash
> them completely.
>
I think I had more crashes with LeonardoSpectrum-Altera than
Altera in-house, but I guess that depends on the design.
> So Quartus 2 1.1 SP2 handle with care.
>
> Having said all that I did evaluate the Xilinix web pack and found its user
> interface much more clunky, and the amount of manual fiddling while great
> for the last ounce of performance is far more of a chore for regular
> run-of-the-mill designs.
>
> Bottom line is I still fight the daily battle with the custard castle
> monster and am getting quite good at predicting/avoiding the crashes.
>
> Paul
>
One thing I really hate about Quartus II 1.1 is that, it drains
System Resources very rapidly like Netscape does in Windows 98.
I know that is not a issue in Windows NT/2000/XP.
I guess I started off with Xilinx tool, so I still prefer ISE WebPACK
4.1 over Quartus II 1.1 Web Edition, but certainly, Quartus II is a huge
improvement over MAX+PLUS II.
Kevin Brace (Don't respond to me directly, respond within the
newsgroup.)
Article: 38852Hi Rickman, > My application is a little different from yours. I won't be using the > JTAG chain to program the Xilinx parts. I will need to use the JTAG > connector to program the MSP430 and to debug it as well as the > TMS320C6711, one at a time, of course. > > The pinout of the two connectors are not the same, but the JTAG pin > functions are similar except for two extra on the MSP430. There is a RST > signal that seems to be needed and a power signal that may be optional, Correct. TI's part have implemented fully compliant JTAG, and those additional signals youe are not part of JTAG specs, but added to aim connection between IAR (KickStart and/or full) tool set and Eval. Board. I've ommited those two signals in my design, but kept the original connector (2x7 pins) in order to avoid doing cable-adapters. (Of course, I added push-button switch for manual reset.) > I'm not sure. I think I can wire a JTAG connector to support all the > signals for the C67 DSP (as well as any other TI DSP) with two extra > pins. These would provide the RST and Vcc signals that the MSP430 > emulator needs. Then an adaptor would be used to connect the IAR > KickStart emulator. All four of my JTAG chips would be in the same > chain. Sure, that would work. In my design I wanted to use Lithium 3.6V batt. with DC/DC to 2.5V and that power line simply didn't fit. It provides (IIRC) 3V 'taken' from Parallel (PC Centronics) port and I didn't want to use it. My emulator was normally powered by PC port but target had it's own supply. > > In my case, this should work assuming that I can get both the DSP and > MSP emulators to work with a scan chain. I have been told by TI DSP > support that Code Composer does support other devices in the scan chain. > I also saw in the setup for my C3x version of Code Composer where you > can add "Bypass" as a device in the chain. So I can probably get that to > work. Sure, that should work from electrical point of view. But, did TI DSP support told you anything about 'Adding' chips into chain, not 'Bypassing' only? I assume that you are aware of the fact that BSDL file for MSP430 don't exist (by the time of writing this) and you will end up writing your own BSDL file for TI part. (That was one reason for my original post on n/g) . But first _make sure_ that MSP430 tool chain can do the same - when you debug/ programm MSP your ISP tool has to have ability to _at least_ bypass the DSP. Now you have a situation of using 'adopted' JTAG connector with two tools: IAR's for MSP430 with (I guess) no ability to neither bypass nor add chips into chain, and Code Composer who has ability to bypass chips. I guess you solve one problem (accessing DSP via JTAG) but another proglem (accessing MSP430 via JTAG) still (might) exists: how IAR's tools will recognize MSP430 within a chain (of more than one chip)? At this point (in my design) I sorta 'gave up' and kept JTAGs separated. (electrically separated) I've used two separate connectors just because I didn't want to mess up with cable-adapters. > > But I have the TI support team working on the question about whether the > MSP430 emulator can do the same thing. Although In my currect design I'm using Atmel ATmega128 parts, I still have some upcoming stuff with MSP430 so please let me know if TI's guys solve that problem. > I have also ordered the Flash > Emulation Tool, so I will be able to check it out myself in a few days. > I belive this includes the same emulation HW/SW are the IAR toolset. It > is just limited in program size. Well, MSP430 comes _only_ with IAR's tool set. Smaller (free) version is called KickStart but essentially it's a stripped-down version of their IAR Workbench where assembler is full, but C compiler can generate only up to 2K of binary code. Full IAR Workbench costs $2500. Recently I hears over Atmel mailer-list that ImageCraft Inc is preparing their ICC, a C compile, to be ported onto MSP430. Well, will see.. That emulator you were talking about is probably a Eval Board with just a JTAG emulator, a nice small package of QFP socket on a small 3x3" PCB with a JTAG connector. The "real" emulator, according to TI supprt, costs 'about' $3000. Cheers, - -D.G. P.S. I'm closing this email behind my n/g name very soon (today!) so you may use my normal email dgacina@hotmail.com_no.spamArticle: 38853
Just released on opencores : RISC5X A small RISC CPU (written in VHDL) that is compatible with the 12 bit opcode PIC family. Single cycle operation normally, two cycles when the program counter is modified. Clock speeds of over 40Mhz are possible when using the Xilinx Virtex optimisations. The core has a single pipeline stage and is run from a single clock, so (ignoring program counter changes) a 40Mhz clock will give 40 MIPS processing speed. Any instruction which modifies the program counter, for example a branch or skip, will result in a pipeline stall and this will only cost one additional clock cycle. The CPU architecture chosen is not particularly FPGA friendly, for example multiplexers are generally quite expensive. The maximum combinatorial path delay is also long, so to ease the place and route tool's job the core is written at a low level. It instantiates a number of library macros, for example a 4:1 mux. Two versions of these are given, one is generic VHDL and the second is optimised for Xilinx Virtex series (including sparten2's etc). A constraints file locates the datapath macros within the device and ensures an easy fit and high clock speed. http://www.opencores.org/projects/risc5x/ mikej<NO SPAM>@opencores.orgArticle: 38854
cn99 a écrit : > I'm afraid that kind of computer is only appropriate for special use, e.g. a > webserver with very limited ability. Besides, a FPGA-based computer won't > reach as high frequecy as required by many applications. do you mean that a real 1MHz 6502 or 8 Mhz 8051 is faster than a design implemented in a 20 mHz FPGA? -- http://www.pascaland.org/ compilateurs, sources et liens langage pascal, delphi http://franck.pissotte.free.fr/ mon vide grenier: vieux materiels, logiciels, livres et revuesArticle: 38855
David Findlay a écrit : > Is it possible to build a homebrew computer of some description using FPGA's? I know it won't be > as powerful as a PC, but I'm more interested in designing and building my own. Also does anyone > know of an FPGA simulator for Linux? Thanks, i have the same interest. if you find some ressource please post here. evaluation board seem expensive. for 100$ digilent seem good but with shipping, curstoms tax and money order (i am in france) it will cost 50$ more. and even in Paris fpga are not sold in shops. i am looking for a free design DIY FPGA board. should use a PLCC84, use standard part i have in my box or buy at low price, and have free software running on win98. any url? thanks -- http://www.pascaland.org/ compilateurs, sources et liens langage pascal, delphi http://franck.pissotte.free.fr/ mon vide grenier: vieux materiels, logiciels, livres et revuesArticle: 38856
"DG_1" <dgacina@san.rr.com_no.spam> kirjoitti viestissä:lbp08.100459$AI.26190323@typhoon.san.rr.com... > Thanks 'rickman'. > The only problem I 'foresee' is the fact that IAR Kickstart doesn't > have any capability of adding/editing BSDL files (or I missed something). > Therefore, I don't see the way how to use debugging features > of IAR Kickstart when _more_ than one chip is in the same chain. > I guess, designers of IAR's tool-set didn't (intentionally?) > though-out that possibility. Also, I guess, from Xilinx's perspective, > having MSP430 in the same chain is no big deal, just add BSDL > file for TI's part to Xilinx's 'JTAG programmer' tool. I assume you have bought the MSP430 flash tool (kickstart kit?) and possibly already have one of the Xilinx kits, for example those provided by Insight Memec? Have you tried to simply put the two kits in chain as it, i.e., wire the TDO of the first kit to the TDI of the second and read the TDO from the second kit instead of the first, provide electricity to both kits and connect your JTAG-cable to the system? That looks to me rather easy to carry out and should give answers with least pain and buck wasted. =) I haven't tried it myself out yet but when I will start my first MSP430 project that is likely to happen although MSP430 is far better than the average 8-bit MCU when it comes to pin number and hence there is less need for an external PLD. Sincerely, MattiArticle: 38857
Hi, According to Altera datasheet I made my own ByteBlaster programmer board for programming FLEXes and MAXes. Up to now everything worked with minor problems. There was only a limitation of the programmer cable lenght. Two weeks ago I have purchused a new fast computer (Athlon 1600+). Then I have realized that I can not program any chips. Cutting the cable down to 20cm helped but it is rather difficult to work with such a short cable. Changing BIOS parallel port properties did not help - I tried this. And there is a question: are there any problems with the original ByteBlaster (LPT) board used with these new fast computers or I should rather go for USB programmer cable? Does it work with +5V chips? Is it expensive? -- Pozdrowienia, Marcin E. Hamerla "Nienawidze turystow."Article: 38858
Sometimes these problems are helped by using an add-on printer port card rather than the port on the motherboard. "Marcin E. Hamerla" <mehamerla@.........pl> wrote > According to Altera datasheet I made my own ByteBlaster programmer > board for programming FLEXes and MAXes. Up to now everything worked > with minor problems. There was only a limitation of the programmer > cable lenght. Two weeks ago I have purchused a new fast computer > (Athlon 1600+). Then I have realized that I can not program any > chips. Cutting the cable down to 20cm helped but it is rather > difficult to work with such a short cable. Changing BIOS parallel port > properties did not help - I tried this. And there is a question: are > there any problems with the original ByteBlaster (LPT) board used with > these new fast computers or I should rather go for USB programmer > cable? Does it work with +5V chips? Is it expensive?Article: 38859
Shawn, I have been using Synplicity for years. I wouldn't use anything else. And yes we have tried the competition (we always keep our options open). Synplicity outperforms them. If your budget allows, go with the best. Regards, Matt "Shawn" <shineline@home.com> wrote in message news:wL_38.879$8d1.61139@news1.rdc1.md.home.com... > I have been using FPGA express with the Xilinx foundation software. I > found it to be a good tool. Unfortunately, Xilinx will no longer be > supplying FPGA express with its other software. Does anyone know if there > the Xilinx synthesis tool (XST) is comparable in performance to FPGA > Express? Is there an article comparing the performance of the major > synthesis tools for Xilinx (FPGA Express, Exemplar, Synplicity, XST, etc)? > The majority of the people I have spoken with seem to prefer Synplicity, but > the majority of them have very limited or no exposure to the other tools. > > Thank you in advance, > Shawn Hineline > > -- > ******************************* > Shawn Hineline > Optimum Engineering, Inc. > > >Article: 38860
Hey everyone,
I'm in the conecptual phase of a design which I know will be implemented
on a XC4010. Since I'm not completely familiar with that part, I'd
appreciate some advice:
I'm trying to implement a stacked-register entity; each register will
have an input, an output, and 4 levels of stacking, which will be used when
an interrupt is received. That is: on an interrupt, the contents of the
register will be pushed, to be restred when the ISR has completed.
This means that each flop in the register must have 3 inputs: an input
from the data bus, an input from the stack level below it (for popping) and
an nuput from the stack level above it (for pushing). Similarly, each flop
has 3 outputs.
My question is: what are the pros and cons of instantiating muliplexors vs.
tri-stating a couple of small busses for each flop? This is still in the
planning phase, so I'm considering both gate count and speed.
Thanks..
Josh Pfrimmer
Article: 38861Falk Brunner wrote: > > "Russell Shaw" <rjshaw@iprimus.com.au> schrieb im Newsbeitrag > news:3C523652.20E70608@iprimus.com.au... > > > > > What does the fpga editor show, and what do you need it for? > > It shows the low level schematics of your FPGA, with all details of the > CLBS, all routing etc. So, it's a schematic? (like D-flip-flop and AND-gate symbols etc?) > In general, you need this only for Maximum > performance trims of your design. The average user dont need it at all. But > it gives you nice insight into the architecture and how to do good designs. > Hmm, maybe the average user needs this too??.Article: 38862
"Marcin E. Hamerla" wrote: > > Hi, > > According to Altera datasheet I made my own ByteBlaster programmer > board for programming FLEXes and MAXes. Up to now everything worked > with minor problems. There was only a limitation of the programmer > cable lenght. Two weeks ago I have purchused a new fast computer > (Athlon 1600+). Then I have realized that I can not program any > chips. Cutting the cable down to 20cm helped but it is rather > difficult to work with such a short cable. Changing BIOS parallel port > properties did not help - I tried this. And there is a question: are > there any problems with the original ByteBlaster (LPT) board used with > these new fast computers or I should rather go for USB programmer > cable? Does it work with +5V chips? Is it expensive? IIRC, the published byteblasterMV schematic doesn't show the bypass cap. Put a 100nF cap across the supply of the HC244 or whatever.Article: 38863
Russell Shaw wrote:
>
> Falk Brunner wrote:
> >
> > It shows the low level schematics of your FPGA, with all details of the
> > CLBS, all routing etc.
>
> So, it's a schematic? (like D-flip-flop and AND-gate symbols etc?)
>
The thing about LUT (Look Up Table)-based FPGAs is that all
those AND, OR, and NOT gates get converted, and mapped into LUTs when
you compile your schematics (synthesis in HDL), mapped it to LUTs, and
P&R the circuit.
Like LUTs, FFs are fixed resources of the FPGA, so FFs won't be created
from LUTs.
I don't know the detailed history of LUT-based FPGAs, but I heard that
Xilinx was the first company to come up with a 4-input LUT-based FPGA.
Later, Altera also came up with their own FPGA that also was a 4-input
LUT-based FPGA, so Xilinx sued Altera for patent infringement.
They settled the lawsuit recently by Altera agreeing to pay $20 million
to Xilinx.
My guess is that, for Altera, $20 million perhaps was a year or so worth
of legal fees it was paying to lawyers, so from Altera's perspective, it
was wise to settle the lawsuit.
The reason Altera used to, and may still call their 4-input LUT-based
FPGAs as CPLDs is because of the lawsuit.
Altera claims that their FPGAs have different routing structure than
Xilinx's, so supposedly that is the reason Altera calls their FPGAs as
CPLDs, but that seems like a desperate way to avoid Xilinx's
accusations.
The basic idea behind a 4-input LUT which I didn't understand
too well until recently is that ANY complex 4-input function can be
represented by a 4-input LUT.
Let's say you have 4-inputs A, B, C, and D, and the equation for X is
ACD# + A#BC#D + AB# + ABD#.
I haven't figured out how many NAND gates the above equation for X will
require (I just came up with the equation at random.), but when function
X gets mapped into a 4-input LUT, the value of X will be precomputed,
and the results (0 or 1) for function X will be stored in a 16 bit (2 ^
4 inputs = 16 bits) memory storage called a 4-input LUT.
The output for X will depend on the inputs A, B, C, and D, and based on
the input, the LUT will read the appropriate value.
When the input changes, the LUT reads a different value.
I am sure there are other people who can explain how 4-input LUT works
better than I can, but what I want to say is that a LUT-based FPGA is
basically an SRAM chip with lots of wiring resources to emulate digital
logic circuits.
If someone noticed a mistake in what I wrote, let me know.
Kevin Brace (Don't respond to me directly, respond within the
newsgroup.)
Article: 38864A few comments from the Xilinx perspective: The XC4010 is a 10-year old design. Following my postulate that ICs "age" fifteen times faster than humans, this is equivalent to a 150 year old "very-senior citizen". Don't start a new project with it. As a minimum, use the 3.3-V -XL version. Better would be Virtex or Spartan-II. I would implement your stack in the LUT-RAM. In Xilinx FPGAs you can use any 16-bit look-up table as a 16-bit RAM. Then you have push and pull with a common 4-bit counter, and the stack can have any depth up to 16 levels ( for the same low cost) Your original question: 3-stated Longlines vs multiplexers: 3-state Longlines force your floorplan, which may be good or bad. When your sources are properly aligned, the 3-state multipelxing is almost free. You might create contention, but only when you make mistakes in the select logic. I vote for 3-state, especially since you have chosen Xilinx FPGAs already. I think 3-state is not availabel with other manufacturers. Peter Alfke, Xilinx Applications ========================= Josh Pfrimmer wrote: > Hey everyone, > I'm in the conecptual phase of a design which I know will be implemented > on a XC4010. Since I'm not completely familiar with that part, I'd > appreciate some advice: > > I'm trying to implement a stacked-register entity; each register will > have an input, an output, and 4 levels of stacking, which will be used when > an interrupt is received. That is: on an interrupt, the contents of the > register will be pushed, to be restred when the ISR has completed. > > This means that each flop in the register must have 3 inputs: an input > from the data bus, an input from the stack level below it (for popping) and > an nuput from the stack level above it (for pushing). Similarly, each flop > has 3 outputs. > > My question is: what are the pros and cons of instantiating muliplexors vs. > tri-stating a couple of small busses for each flop? This is still in the > planning phase, so I'm considering both gate count and speed. > > Thanks.. > > Josh PfrimmerArticle: 38865
Kevin Brace wrote > The thing about LUT (Look Up Table)-based FPGAs is that all > those AND, OR, and NOT gates get converted, and mapped into LUTs when > you compile your schematics (synthesis in HDL), mapped it to LUTs, and > P&R the circuit. > Like LUTs, FFs are fixed resources of the FPGA, so FFs won't be created > from LUTs. > I don't know the detailed history of LUT-based FPGAs, but I heard that > Xilinx was the first company to come up with a 4-input LUT-based FPGA. Yes, a 4-input LUT can implement any function of 4 variables, and there exist 65,536 different functions of four variables, counting all permutations etc. ( Anybody I interviewed for a Xilinx Applications Engineering job during the past 14 years had to be able to derive or prove this, otherwise they flunked the interview.) Calling a Xilinx FPGA "SRAM-based" is a commonly used sloppy nomenclature. The logic is Look-up-table based, and nowadays includes many additional structures like BlockRAM etc. The configuration ( 90% of it controlling interconnect, not logic ) is stored in latches, cross-coupled gates. These latches have some similarity ( and also some dissimilarity) with SRAM cells. That's why we - reluctantly - tolerate the name "SRAM-based". The manufacturing process is identical to microprocessors, not to SRAMs. The alternatives for programmable logic are EEPROM or Flash based technology, or antifuse one-time programmable technology. Each technology has advantages and disadvantages ( and its own fan community) but "SRAM-based" FPGAs represent the fastest growing market, dominating the high-complexity field. Peter Alfke, Xilinx ApplicationsArticle: 38866
> However, from what I see in an initiator write waveforms in LogiCORE > PCI Design Guide Page 13-8 (Figure 13-3), Page 13-10 (Figure 13-5), > and Page 14-19 (Figure 14-6), COMPLETE is asserted on the user side > at the same the user side loads the last data on ADIO. Yeah, that's pretty much what I thought, however the language is rather vague about the exact, detailed interpretation of this signal. I had hoped for my reading of the waveforms (and my experimentations with simulations) to be confirmed by someone else (hello Xilinx!) who has direct experience with the core. > Looking at the waveforms, COMPLETE seems to be asserted until M_DATA > is deasserted, like the way you worded. You are supposed to assert COMPLETE until the transaction is completed. > If the initiator is doing only a single cycle transfer, COMPLETE > seems like it has to be asserted on the next cycle REQUEST is > asserted (Figure 12-4, 12-5, 12-6, 12-7, and 12-8), and has to be > kept asserted until M_DATA is deasserted. In fact, empirically, it seems that you can assert it as late as that first cycle in which M_DATA and M_SRC_EN go high and still transfer only one word. I imagine that they suggest that COMPLETE and REQUEST be asserted at the same time for ease of implementation. > So, from what I see, it looks like COMPLETE assertion timing will be > different depending on whether or not the transfer is a single or a > burst. In practice, initiator transfer can be interrupted by a You see why I find the exact interpretation of COMPLETE somewhat unclear. :) > target disconnect or a target abort, and when that happens, > COMPLETE seems to get ignored (FRAME# will be deasserted if already > asserted because STOP# was deasserted.). Right. I made some major changes to the initiator logic in my design here, and I will see how these changes affect the result. The CSR vector provides all sorts of useful bits (documented in chapter 2 of the user guide) for determining transaction state. When I get these changes into simulation, I'll see what the timing of these bits is like. PERL programmers are familiar with the expression TMTOWTDI[1]. I think TMTOWTDI applies equally well to Xilinx's PCI logicore, but it is difficult to be certain that you aren't digging a hole for yourself by doing things differently from the examples that Xilinx provide without strict definitions of the relevant controls. At the same time it would be a terrible shame for a design's efficiency to suffer for lack of understanding on the part of the designer. [1] There's More Than One Way To Do It -- David Miller, BCMS (Hons) | When something disturbs you, it isn't the Endace Measurement Systems | thing that disturbs you; rather, it is Mobile: +64-21-704-djm | your judgement of it, and you have the Fax: +64-21-304-djm | power to change that. -- Marcus AureliusArticle: 38867
"Mike Johnson opencores.org>" <mikej<NOSPAM> wrote in message news:1012076226.4195.0@eurus.uk.clara.net... > Just released on opencores : > > RISC5X > > A small RISC CPU (written in VHDL) that is compatible with the 12 bit opcode > PIC family. Single cycle operation normally, two cycles when the program > counter is modified. Clock speeds of over 40Mhz are possible when using the > Xilinx Virtex optimisations. Wow, thank you very much, Mike! Simon Ramirez, Consultant Synchronous Design, Inc. Oviedo, FL USAArticle: 38868
Josh Pfrimmer wrote: > I'm trying to implement a stacked-register entity; each register will > have an input, an output, and 4 levels of stacking, which will be used when > an interrupt is received. That is: on an interrupt, the contents of the > register will be pushed, to be restred when the ISR has completed. Naturally, Peter's advice is probably the best you can get. The only thing I can add is my own experience with this question. I found that in a particular Virtex design, tristates were actually slower than multiplexors. It's not clear to me why this was. There were only 3 inputs to choose from, (one of which was a compile-time constant), so I guess it had to do with LUT delay versus BUFT switching time. I guess you have to suck it and see. If you are designing in an HDL, then switching between multiplexors and tristate buffers is trivial. It has to be a very design sensitive matter, so experimentation will yield the best results! -- David Miller, BCMS (Hons) | When something disturbs you, it isn't the Endace Measurement Systems | thing that disturbs you; rather, it is Mobile: +64-21-704-djm | your judgement of it, and you have the Fax: +64-21-304-djm | power to change that. -- Marcus AureliusArticle: 38869
Hi, I am sorry that you have found the description of COMPLETE a bit, um, fuzzy. The example code is provided to obscure the "corner" cases in using this signal. In general, asserting COMPLETE tells the core to deassert FRAME# at the next opportunity. COMPLETE feeds into the next state logic for FRAME#, which is registered in an IOB output flip flop. While this sounds fairly simple, there are several corner cases because this core is pipelined. The user application will be keeping track of how many dataphases it wants to perform (the "transfer counter"). The counter changes based on the M_DATA_VLD signal, which indicates that a dataphase has been completed. However, M_DATA_VLD is a registered function of IRDY# and TRDY#. So, from IRDY# and TRDY#, to the user via M_DATA_VLD, through some logic to COMPLETE, and back to FRAME#, there are two flip flops. Hence, the "corner cases": // Corner case one, I only wanted one dataphase in the first place // and need to assert COMPLETE before I even get any indication // that data transfer has taken place. Assert it immediately. assign FIN1 = CNT1 & REQUEST; // Corner case two, I only wanted two dataphases in the first place // and need to assert COMPLETE so that I will get two dataphases. // If I wait for confirmation of two dataphases, it is too late to // deassert FRAME#. The INIT_WAITED term is there to stall this // event if the user application is inserting wait states as an // initiator. Assert it one cycle after we enter the M_DATA state, // unless we are inserting wait states. assign FIN2 = CNT2 & M_DATAQ & !INIT_WAITED; // General case, I am bursting three or more dataphases, and want to // assert COMPELTE at the right time to get that many dataphases. When // The transfer count hits three, and M_DATA_VLD asserts, that means in // the last clock cycle, on the bus, I have transferred the dataphase // "n-2" of an "n" dataphase burst. assign FIN3 = CNT3 & M_DATA_VLD; // Assert the COMPLETE signal if either of those three have taken place. // There is another term that holds COMPLETE asserted until the deassertion // of M_DATA which I have left out. It is in the design guide. assign ASSERT_COMPLETE = FIN1 | FIN2 | FIN3; Hope this helps, Eric David Miller wrote: > > > However, from what I see in an initiator write waveforms in LogiCORE > > PCI Design Guide Page 13-8 (Figure 13-3), Page 13-10 (Figure 13-5), > > and Page 14-19 (Figure 14-6), COMPLETE is asserted on the user side > > at the same the user side loads the last data on ADIO. > > Yeah, that's pretty much what I thought, however the language is rather > vague about the exact, detailed interpretation of this signal. I had > hoped for my reading of the waveforms (and my experimentations with > simulations) to be confirmed by someone else (hello Xilinx!) who has > direct experience with the core. > > > Looking at the waveforms, COMPLETE seems to be asserted until M_DATA > > is deasserted, like the way you worded. > > You are supposed to assert COMPLETE until the transaction is completed. > > > If the initiator is doing only a single cycle transfer, COMPLETE > > seems like it has to be asserted on the next cycle REQUEST is > > asserted (Figure 12-4, 12-5, 12-6, 12-7, and 12-8), and has to be > > kept asserted until M_DATA is deasserted. > > In fact, empirically, it seems that you can assert it as late as that > first cycle in which M_DATA and M_SRC_EN go high and still transfer only > one word. I imagine that they suggest that COMPLETE and REQUEST be > asserted at the same time for ease of implementation. > > > So, from what I see, it looks like COMPLETE assertion timing will be > > different depending on whether or not the transfer is a single or a > > burst. In practice, initiator transfer can be interrupted by a > > You see why I find the exact interpretation of COMPLETE somewhat unclear. :) > > > target disconnect or a target abort, and when that happens, > > COMPLETE seems to get ignored (FRAME# will be deasserted if already > > asserted because STOP# was deasserted.). > > Right. I made some major changes to the initiator logic in my design > here, and I will see how these changes affect the result. The CSR > vector provides all sorts of useful bits (documented in chapter 2 of the > user guide) for determining transaction state. When I get these changes > into simulation, I'll see what the timing of these bits is like. > > PERL programmers are familiar with the expression TMTOWTDI[1]. I think > TMTOWTDI applies equally well to Xilinx's PCI logicore, but it is > difficult to be certain that you aren't digging a hole for yourself by > doing things differently from the examples that Xilinx provide without > strict definitions of the relevant controls. > > At the same time it would be a terrible shame for a design's efficiency > to suffer for lack of understanding on the part of the designer. > > [1] There's More Than One Way To Do It > -- > David Miller, BCMS (Hons) | When something disturbs you, it isn't the > Endace Measurement Systems | thing that disturbs you; rather, it is > Mobile: +64-21-704-djm | your judgement of it, and you have the > Fax: +64-21-304-djm | power to change that. -- Marcus AureliusArticle: 38870
> I was able to find the problem, which appears to be related to Xilinx > tools. > Here it is: > 1) 3 sets of 14 outputs each when checked with a logic analyzer have > the correct data, but all th bits are inverted. > > 2) The design was simulated functionally before routing -- all is well > (the outputs are not inverted) > > 3) The design was simulated functionally after the routing (.ncd --> > .vhd) > -- all is well (the outputs are not inverted) > > 4) Same as 3) but with timing info (.sdf file) -- all is well (the > outputs are not inverted) > > 5) Manually verified (by using FPGA Editor) that at least 1 of the > outputs does not get inverted. > > The only other step that was performed was the generation of .bit file > from .ncd file. I do not know of a way to go fro .bit file to .ncd > file (or .vhd) to verify the functionality after bit file generation. > I believe that this is where the outputs become inverted. The problem > was fixed by channeling all the desired outputs through the inverted > input to each IOB via FPGA Editor, and then regenerating the new bit > file. > > > Thanks for all help. > > Yury Yury, Very interesting. I was just reading about the Verplex Conformal Logic Equivalency Checker (LEC) in the Xcell Journal Issue 41. If what you say is correct, it would not have found the problem either, cause it uses the Post-Par netlist as its final step, and your timing sim indicated no problem there. Nice find, thanks for sharing it with us. NewmanArticle: 38871
I would second Peter's comments. The use of FFs for your four level stack is not a good use of resources unless you are prototyping for some other chip such as an ASIC. Either way, it is not a good idea to use the t-bufs, however, IMHO. If you are working toward an ASIC, it is not likely that they provide internal t-bufs in their library. If you are only doing a Xilinx design, then you will do much better to use the LUT RAM. Just add a couple of counters and you are done! Well, maybe a little over simplified, but if you are not doing push and pop at the same time and both input and output work off the same clock, (which is what it sounds like) then it is a very simple design indeed. BTW, I also second Peter's suggestion that you don't use the XC4000 family. I seem to remember hearing that it is no longer supported. But that may be overstated and it is only the older members of the family that are off the official support list. The XC4000 parts were state of the art for a long time as they went through many generations. Unlike the newer chips which seem to get redone every three or four years into a brand new family. Kinda like TTL logic vs. the newer CMOS stuff. We had some five or six generations of 74XXX00 parts; std, L, H, S, LS, ALS, F, etc, Each of which had its several years of being the "King of the hill". Now we get many different flavors which all use different supply voltages, interface voltages, tolerance of other interface voltages and package sizes. A new one pops out nearly every year. I doubt that many people would start a new design using any of the original TTL family parts, even the ALS parts. Peter Alfke wrote: > > A few comments from the Xilinx perspective: > > The XC4010 is a 10-year old design. Following my postulate that ICs "age" > fifteen times faster than humans, this is equivalent to a 150 year old > "very-senior citizen". Don't start a new project with it. > As a minimum, use the 3.3-V -XL version. Better would be Virtex or Spartan-II. > > I would implement your stack in the LUT-RAM. In Xilinx FPGAs you can use any > 16-bit look-up table as a 16-bit RAM. Then you have push and pull with a common > 4-bit counter, and the stack can have any depth up to 16 levels ( for the same > low cost) > > Your original question: 3-stated Longlines vs multiplexers: > 3-state Longlines force your floorplan, which may be good or bad. When your > sources are properly aligned, the 3-state multipelxing is almost free. You > might create contention, but only when you make mistakes in the select logic. I > vote for 3-state, especially since you have chosen Xilinx FPGAs already. I > think 3-state is not availabel with other manufacturers. > > Peter Alfke, Xilinx Applications > ========================= > Josh Pfrimmer wrote: > > > Hey everyone, > > I'm in the conecptual phase of a design which I know will be implemented > > on a XC4010. Since I'm not completely familiar with that part, I'd > > appreciate some advice: > > > > I'm trying to implement a stacked-register entity; each register will > > have an input, an output, and 4 levels of stacking, which will be used when > > an interrupt is received. That is: on an interrupt, the contents of the > > register will be pushed, to be restred when the ISR has completed. > > > > This means that each flop in the register must have 3 inputs: an input > > from the data bus, an input from the stack level below it (for popping) and > > an nuput from the stack level above it (for pushing). Similarly, each flop > > has 3 outputs. > > > > My question is: what are the pros and cons of instantiating muliplexors vs. > > tri-stating a couple of small busses for each flop? This is still in the > > planning phase, so I'm considering both gate count and speed. > > > > Thanks.. > > > > Josh Pfrimmer -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 38872
Matti Ruusunen wrote: > > "DG_1" <dgacina@san.rr.com_no.spam> kirjoitti > viestissä:lbp08.100459$AI.26190323@typhoon.san.rr.com... > > Thanks 'rickman'. > > The only problem I 'foresee' is the fact that IAR Kickstart doesn't > > have any capability of adding/editing BSDL files (or I missed something). > > Therefore, I don't see the way how to use debugging features > > of IAR Kickstart when _more_ than one chip is in the same chain. > > I guess, designers of IAR's tool-set didn't (intentionally?) > > though-out that possibility. Also, I guess, from Xilinx's perspective, > > having MSP430 in the same chain is no big deal, just add BSDL > > file for TI's part to Xilinx's 'JTAG programmer' tool. > > I assume you have bought the MSP430 flash tool (kickstart kit?) and possibly > already have one of the Xilinx kits, for example those provided by Insight > Memec? > > Have you tried to simply put the two kits in chain as it, i.e., wire the TDO > of the first kit to the TDI of the second and read the TDO from the second > kit instead of the first, provide electricity to both kits and connect your > JTAG-cable to the system? That looks to me rather easy to carry out and > should give answers with least pain and buck wasted. =) > > I haven't tried it myself out yet but when I will start my first MSP430 > project that is likely to happen although MSP430 is far better than the > average 8-bit MCU when it comes to pin number and hence there is less need > for an external PLD. > > Sincerely, > Matti You don't even have to connect the two chains. If there is no provision to add other components to the scan list, then it won't work. So you only need to look at the documentation or the software. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 38873
Many thanks, all. I'm stuck with the 4010: it's already on the board. I've done some Virtex work before, and, were it up to me, would definately go that way... but, alas. JP "rickman" <spamgoeshere4@yahoo.com> wrote in message news:3C539B0A.2AF76194@yahoo.com... > I would second Peter's comments. The use of FFs for your four level > stack is not a good use of resources unless you are prototyping for some > other chip such as an ASIC. Either way, it is not a good idea to use the > t-bufs, however, IMHO. If you are working toward an ASIC, it is not > likely that they provide internal t-bufs in their library. If you are > only doing a Xilinx design, then you will do much better to use the LUT > RAM. Just add a couple of counters and you are done! Well, maybe a > little over simplified, but if you are not doing push and pop at the > same time and both input and output work off the same clock, (which is > what it sounds like) then it is a very simple design indeed. > > BTW, I also second Peter's suggestion that you don't use the XC4000 > family. I seem to remember hearing that it is no longer supported. But > that may be overstated and it is only the older members of the family > that are off the official support list. The XC4000 parts were state of > the art for a long time as they went through many generations. Unlike > the newer chips which seem to get redone every three or four years into > a brand new family. Kinda like TTL logic vs. the newer CMOS stuff. We > had some five or six generations of 74XXX00 parts; std, L, H, S, LS, > ALS, F, etc, Each of which had its several years of being the "King of > the hill". Now we get many different flavors which all use different > supply voltages, interface voltages, tolerance of other interface > voltages and package sizes. A new one pops out nearly every year. I > doubt that many people would start a new design using any of the > original TTL family parts, even the ALS parts. > > > Peter Alfke wrote: > > > > A few comments from the Xilinx perspective: > > > > The XC4010 is a 10-year old design. Following my postulate that ICs "age" > > fifteen times faster than humans, this is equivalent to a 150 year old > > "very-senior citizen". Don't start a new project with it. > > As a minimum, use the 3.3-V -XL version. Better would be Virtex or Spartan-II. > > > > I would implement your stack in the LUT-RAM. In Xilinx FPGAs you can use any > > 16-bit look-up table as a 16-bit RAM. Then you have push and pull with a common > > 4-bit counter, and the stack can have any depth up to 16 levels ( for the same > > low cost) > > > > Your original question: 3-stated Longlines vs multiplexers: > > 3-state Longlines force your floorplan, which may be good or bad. When your > > sources are properly aligned, the 3-state multipelxing is almost free. You > > might create contention, but only when you make mistakes in the select logic. I > > vote for 3-state, especially since you have chosen Xilinx FPGAs already. I > > think 3-state is not availabel with other manufacturers. > > > > Peter Alfke, Xilinx Applications > > ========================= > > Josh Pfrimmer wrote: > > > > > Hey everyone, > > > I'm in the conecptual phase of a design which I know will be implemented > > > on a XC4010. Since I'm not completely familiar with that part, I'd > > > appreciate some advice: > > > > > > I'm trying to implement a stacked-register entity; each register will > > > have an input, an output, and 4 levels of stacking, which will be used when > > > an interrupt is received. That is: on an interrupt, the contents of the > > > register will be pushed, to be restred when the ISR has completed. > > > > > > This means that each flop in the register must have 3 inputs: an input > > > from the data bus, an input from the stack level below it (for popping) and > > > an nuput from the stack level above it (for pushing). Similarly, each flop > > > has 3 outputs. > > > > > > My question is: what are the pros and cons of instantiating muliplexors vs. > > > tri-stating a couple of small busses for each flop? This is still in the > > > planning phase, so I'm considering both gate count and speed. > > > > > > Thanks.. > > > > > > Josh Pfrimmer > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 38874
DG_1 wrote: > Correct. TI's part have implemented fully compliant JTAG, and those > additional signals youe are not part of JTAG specs, but added to aim > connection between IAR (KickStart and/or full) tool set and Eval. Board. > I've ommited those two signals in my design, but kept the original > connector (2x7 pins) in order to avoid doing cable-adapters. > (Of course, I added push-button switch for manual reset.) I am not sure you can use the Kickstart emulator without one or the other of the two Vcc connections. The documentation says that the emulator needs your Vcc level to adjust the IO signal voltage levels. The serial programming adaptor is slightly different and the levels can be adjusted in software. Remember the MSP430 can be operated at Vcc from 3.3 downto 1.8 volts, if you don't have the IO signal levels correct, it will blow. This part is not 5 volt or even 3.3 volt tolerant when powered from lower voltages. The max Vio spec is Vcc+0.3 volts. I am also not sure if you can omit the RST. I expect that the emulator software wants control over the RST signal. Some JTAG setups provide a TRST signal which should be optional as the JTAG spec provides a way to always put the JTAG interface into a known state. But some emulators use it and I would guess that is what the RST signal is for. If you want to leave it off, try it by cutting the trace on the FET demo board or something similar before you commit to that on your board. > Sure, that would work. In my design I wanted to use Lithium 3.6V batt. > with DC/DC to 2.5V and that power line simply didn't fit. It provides > (IIRC) 3V 'taken' from Parallel (PC Centronics) port and I didn't want > to use it. My emulator was normally powered by PC port but target > had it's own supply. This is what the Vcc sense is for. If you are running at 2.5 volts, you have to let the emulator know to not drive to 3.3 volts on the IOs. > Sure, that should work from electrical point of view. But, did TI DSP > support > told you anything about 'Adding' chips into chain, not 'Bypassing' only? > I assume that you are aware of the fact that BSDL file for MSP430 don't > exist (by the time of writing this) and you will end up writing your own > BSDL > file for TI part. (That was one reason for my original post on n/g) . The documentation on Code Composer is pretty clear. It appears that they put the same effort into using their parts in a boundry scan chain as Xilinx did. See below... =================== Scanning Through Non-debug JTAG devices It is also possible to scan information through the JTAG ports of devices that are not being debugged via the TI Emulator. This condition arises if a customer wants to perform Boundary Scan on devices within their target board. Boundary scan is performed using the JTAG header as well, but it uses different software than is used for TI’s emulation. When devices are included in the JTAG scan path but are not being emulated, it is possible to scan the emulation information through these devices by putting them in BYPASS mode. It is first necessary to understand how large their JTAG Instruction Registers are. ==================== > But first > _make sure_ that MSP430 tool chain can do the same - when you debug/ > programm MSP your ISP tool has to have ability to _at least_ bypass the DSP. > Now you have a situation of using 'adopted' JTAG connector with > two tools: IAR's for MSP430 with (I guess) no ability to neither bypass nor > add chips into chain, and Code Composer who has ability to bypass chips. > I guess you solve one problem (accessing DSP via JTAG) but another > proglem (accessing MSP430 via JTAG) still (might) exists: how IAR's > tools will recognize MSP430 within a chain (of more than one chip)? > At this point (in my design) I sorta 'gave up' and kept JTAGs separated. > (electrically separated) I've used two separate connectors just because > I didn't want to mess up with cable-adapters. That is the easy way for debug. But boundry scan is very useful in production. You might want to provide a jumper to allow the two chains to be combined. But watch your trace lengths. They seem very particular about keeping them under 6 inches without buffering. > > But I have the TI support team working on the question about whether the > > MSP430 emulator can do the same thing. > Although In my currect design I'm using Atmel ATmega128 parts, I still have > some upcoming stuff with MSP430 so please let me know if TI's guys solve > that problem. Since the tools come from IAR, I will bet this is a question that was not handled as it should have been. IAR is strictly an emulation tool company and I bet they are not in tune with production issues. > Well, MSP430 comes _only_ with IAR's tool set. Smaller (free) version > is called KickStart but essentially it's a stripped-down version of their > IAR Workbench where assembler is full, but C compiler can generate only > up to 2K of binary code. Full IAR Workbench costs $2500. > Recently I hears over Atmel mailer-list that ImageCraft Inc is preparing > their ICC, a C compile, to be ported onto MSP430. Well, will see.. > That emulator you were talking about is probably a Eval Board with just a > JTAG emulator, a nice small package of QFP socket on a small 3x3" PCB > with a JTAG connector. The "real" emulator, according to TI supprt, costs > 'about' $3000. I tried to get info on the IAR tool since it is not smart to try to use "cheap" tools. But they seem to provide very limited info on their web site. I may take another look and if needed, I'll give them a call. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
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