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
I've just entered the world of logic design and have started using Altera's MaxPlus II baseline software (because it's free :-) ). I am trying to design a cpu core, just to get acquainted with things, and have realised that the limiting factor in such a core is the delay time for an adder. I've tested the speed of an adder (in MaxPlus, I've created a project with two 32-bit inputs, one 32-bit output, and a 32-bit lpm_add_sub). The problem is that I get a delay time of over 17ns for this add. It was much more before enabled carry chains (which didn't seem to be enabled by default ??) and now the floorplan editor shows the cells being laid out in parallel columns nicely linked with carry chains. Is 17ns what I should expect for such an adder. I was told by a Xilinx employee that this is ridiculous and that it should only take 5.3ns (for their Vertex E-series). This means I'm out by a factor of more than three. I've emailed Altera technical support several times and, whilst very prompt and willing in their replies, they have completely failed to address my central question : how long should a 32-bit add take. I hoped that mentioning that their arch nemesis's Virtex chip could perform this add in 5.3ns would precipitate an immediate response to this but they don't seem to have risen to the bait. Is anyone else using MaxPlus 2 for a datapath design involving adders and, if so, what kind of delays are you getting ? Thanks - Steve Logue wslogue@world-callnet.comArticle: 23851
"Nicholas C. Weaver" <nweaver@boom.CS.Berkeley.EDU> wrote in message > C++
doesn't even attempt metalinguistic abstractions, and
> Java's (the Reflection interface) is almost hopelessly crippled by
> security restrictions. And Java doesn't have good overloading
> mechanisms of operators, which would make the syntax much cleaner for
> many operations.
I have designed working and prototype/sketch generators in C++ and Java and
I have found exactly this. However, in practice, I think the benefits of
C++ operator overloading are worth the hassle of "introducing' C++'s member
data to themselves" with lightweight _ macros (as shown below):
(This is not CNets, just a sketch of some newer ideas since:)
// mymuxes.h -- user application -- some muxes:
#include "module.h"
module(Mux2) { // define a 2-1 mux
In a, b, sel;
Out o;
implement(Mux2) _4(a,b,sel,o) as { o = a&~sel | b&sel; /*=> FMAP*/ }
};
module(Mux4) { // define a 4-1 mux as a composition of three 2-1 muxes
In a, b, c, d, sel1, sel2;
Out o;
Net o1, o2;
Mux2 m1, m2, m3;
implement(Mux4) _7(a,b,c,d,sel1,sel2,o), _5(o1,o2,m1,m2,m3) as {
m1.a(a).b(b).sel(sel1).o(o1).rloc(0,0);
m2.a(c).b(d).sel(sel1).o(o2).rloc(0,0);
m3.a(o1).b(o2).sel(sel2).o(o).rloc(0,1);
}
};
// module.h -- standard module generator header
struct Module;
extern stack<Module*> modules; // currently 'open' modules being defined
struct Net { ... };
struct Entity : Net {
string name;
Entity(string name) { this->name = name; modules.top()->addEntity(name,
this); }
Entity& connect(Net& net) { ... }
}
struct Module : Entity {
map<string,Entity*> members;
Module(string name) : Entity(name) { modules.push(this); }
Module& connect(string name, Net& net) { members.at(name)->connect(net);
return *this; }
Module& rloc(int r, int c) { ... return *this; }
Module& p(Net& net) { return connect("p", net); }
#define p(port) Module& port(Net& net) { return connect(#port, net); }
#include "stdports.h"
#include "userports.h"
#undef p
};
struct LastMember {
LastMember() { modules.pop(); }
};
// reflection support
#define _(member) member(#member)
#define _1(a) _(a)
#define _2(a,b) _(a),_b()
#define _3(a,b,c) _(a),_(b),_(c)
#define _4(a,b,c,d) _(a),_(b),_(c),_(d)
#define _5(a,b,c,d,e) _(a),_(b),_(c),_(d),_(e)
#define _6(a,b,c,d,e,f) _(a),_(b),_(c),_(d),_(e),_(f)
#define _7(a,b,c,d,e,f,g) _(a),_(b),_(c),_(d),_(e),_(f),_(g)
#define _8(a,b,c,d,e,f,g,h) _(a),_(b),_(c),_(d),_(e),_(f),_(g),_(h)
#define _9(a,b,c,d,e,f,g,h,i) _(a),_(b),_(c),_(d),_(e),_(f),_(g),_(h),_(i)
#define _10(a,b,c,d,e,f,g,h,i,j)
_(a),_(b),_(c),_(d),_(e),_(f),_(g),_(h),_(i),_(j)
#define _11(a,b,c,d,e,f,g,h,i,j,k)
_(a),_(b),_(c),_(d),_(e),_(f),_(g),_(h),_(i),_(j),_(k)
#define _12(a,b,c,d,e,f,g,h,i,j,k,l)
_(a),_(b),_(c),_(d),_(e),_(f),_(g),_(h),_(i),_(j),_(k),_(l)
#define module(M) struct M : public Module
#define implement(M) LastMember __end; M(string name) : Module(name),
#define as,__end()
// stdports.h -- standard port names
p(a) p(b) ... p(o) p(q) ... p(z)
// userports.h -- user application port names:
p(m1) p(m2) p(m3)
p(o1) p(o2)
p(sel) p(sel1) p(sel2) p(sel3)
That's the sketch. This may not mean a lot to most of you, but may mean
something to Nicholas. :-) Does it work? I don't know.
Jan Gray
Gray Research LLC
Article: 23852
Hi !
32-bit adder's time approximately 8.5 ns or 117 MHz for EP1K10QC208
device with speed grade -1. Inputs dataa[] and datab[] was feeds
inputs though DFF's and result[] output of LPM_ADD_SUB megafunction
aslo feeds outputs through DFF's. All DFF's was clocked by common
clock line. All DFF's was placed to IOB's.
But, in the real systems internal adders feeds internal
CLB-registers
with minimum row|column interconnection distances and frequency may be
more....
Steve Logue wrote ...
>
>I've tested the speed of an adder (in MaxPlus, I've created a project
>with two 32-bit inputs, one 32-bit output, and a 32-bit lpm_add_sub).
>
>Is 17ns what I should expect for such an adder. I was told by a Xilinx
>employee that this is ridiculous and that it should only take 5.3ns
>(for their Vertex E-series). This means I'm out by a factor of more
>than three.
>
>
>Is anyone else using MaxPlus 2 for a datapath design involving adders
>and, if so, what kind of delays are you getting ?
>
>Thanks - Steve Logue wslogue@world-callnet.com
>
Article: 23853Hi all, If somebody know about inexpensive serial eprom programmer?Article: 23854
In the foundation 2.1i software the tutorials are only for the<br> SpartanXL. Are there any tutorials available for the Vertex?Article: 23855
This is way off topic. I'm thinking it's time to leave my cushy science job in Chicago and move to the West Coast. The scariest aspect of this is the nightmare stories I've heard about the difficulties of finding a place to live in Silicon Valley and the Bay area. Is it really that bad? Are there areas that are better/worse than others? Will I be spending hours per day in my car trying to get to work? -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 23856
This is a subject I am very interested in since I wish to do board level testing using JTAG and boundry scan. I don't think you need to do simulate your test vectors since normally the JTAG chips are not functional while you do the testing. Also, I don't see where it is very useful to run a test simulation when you can normally run the test on a real board much faster. My understanding of how to do board level testing using boundry scan is to think of all the JTAG chips as empty boxes with boundry scan shift registers connected to the IO pins. The goal of this testing is to test the board, the connections to the board and the remaining components (non-JTAG) on the board. This is done with knowledge of how the chips are wired together. On the lowest level, you generate test vectors that can be used to verify that a given output of a JTAG chip is connected to a given input of a JTAG chip and no other JTAG chip inputs or outputs. In other words I see this as a net test. One way to do this is to output all 0's except for one output which is at a 1. Verify that the connected inputs are 1's and all other inputs are 0's. Change the stimulus so that a different output is at a 1 and repeat until all outputs are verified as 1's while all others are at 0. Then repeat this test for all 1's except for a single 0 output. At the next level, you need to test other, non-JTAG componenets such as memory, buffers/registers and anything else that you have on the board. This must be done ad-hoc as each component dictates how it is to be tested. If you have test connections to the board IO connectors, you can test these as well. This is my spin on it. I have not seen much in the way of software to support this other than the stuff from JTAG Technologies and one or two others. None of these companies seem interested enough in my business to respond to my enquiries and don't really explain how or what their software does on their web site. So I have to treat them as not having a product until they show me differently. Are there any share/freeware/open source tools out there for building board level test patterns? Franz Hollerer wrote: > > Hi, > > I have to automate board level tests with tools from JTAG technologies. > The documentation gives an overview. But I don't exactly know how to > start. I miss the "big idea". > > Questions: > 1) How can I test the test vectors. Is it possible to simulate the test > and > different failures? > > 2) JTAG Technologies uses a Boundary-scan Test Specification Language > (BTSL). > I believe that this is a proprietary solution, isn't it? > > 3) I would like to write the tests in VHDL and simulate them. Would it > be possible > to create BTSL files (application data file .apl, general data file > .gen, ...) for the > JTAG tools from this VHDL source? > > Thx > Franz Hollerer > > -- > Institut fuer Hochenegiephysik > Nikolsdorfer Gasse 18 > 1050 Wien > Austria > > Tel: (+43-1)5447328/50 -- Rick 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23857
Some of your information seems to indicate that there is a hold time violation, but I don't know that I believe this. First, I am not clear that a hold time violation would cause the symptom that you describe, although it may be possible. Second, everything that I have read here and on the Xilinx web site indicates that the hold time of internal FFs are guaranteed for FF run off of a global clock buffer. In fact the self feedback you are describing is almost guaranteed by design to work, especially when there is a LUT for delay in the path. Since the worse case is a FF with an early clock feeding a FF with a late clock, your case of a FF feeding itself should be much more likely to work. Finally, if this was a hold time problem as you think, simple counters would not work since they have a single LUT in the feedback path. So if I were you, I would look elsewhere for the cause of the problem. I think you should take a look at the glitching clock that Bob Pearlman mentioned. That will almost certainly give you the symptoms you are describing and can be very hard to see on a scope. Seeing this sort of thing requires not only a very good scope, but it requires a very clean connection to the signal under test. I have seen (or not seen) many problems appear invisible because a ground lead was more than an inch long. The best ground lead is a paper clip wrapped around the ground ring with a bit protruding parallel to the tip and the same length. It should be bent so that you can contact the signal and a ground point at the same time. ANY ground lead with a wire over an inch long will pick up stray RF and mask the fast glitches. How long is the total PCB trace for the C54 STB signal? With the fast edges generated, this can ring or you can have ground bounce from the FPGA outputs that will give you a double clock. How many other output signals on the FPGA are changing at the same time? How many of those are "FAST" outputs? Take a look at your ground pins, are they well connected to GND with very short traces? Do you have adequate decoupling caps with *extremely* short traces? What is the timing of the glitch, 1nS, 2nS... >10nS? An emperical test that you can try is to just put a small capacitance on the clock input pin such as a scope probe or a 10 pf cap. If the problem goes away it is very likly a clock problem and not a chip problem. Matt Gavin wrote: > > Bob, > > thanks much for your comments. I will check the scope/probe I am using, > but I suspect it isn't close to 1GHz. > > In reference to your question about signals that condition the > toggle flop: The only inputs to the flop are its own output, and signals > which are synchronous to the clock (which I do have on a global buffer). > These signals all are setup early since I am using numerous wait states. > So there should be no metastability issues due to asynchronous inputs > toggling just when the clock rises. > > Actually, the clock is a "strobe" which asserts for a bus cycle to my FPGA > (IOSTRBF from the TI C54 DSP). > Its rising edge clocks in data, address and control signals which stay > asserted > for a clock cycle after the strobe rises. > These (address and control) are decoded to toggle the flop input > when a read is done to a specific address. > > FYI, I looked at the original gates in the Xilinx FPGA Editor (nice tool, > BTW) > and there are two muxes and a LUT in the feedback path that > seems to be failing. (so there is at least SOME delay there.) > > Thanks, > > Matt -- Rick 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23858
Hal Murray wrote: > If you are a programmer, then using a library package from c or Java > as a generator feels just like schematics - each box on a schematic > turns into a subroutine call. You call a subroutine to make a gate > or flip-flop. The library provides a collection of primitives - just > like the schematic package does. You can easily extend what the system > provides by writing your own code. The library remembers each call > in an internal data structure. At the end, you call a cleanup routine > which writes out the net list. I understand this. I assume the the variables in the parameter list would be the signals or wires? > If you have that internal data structure, it's pretty easy to > add a simulator to the package. > > The advantages and disadvantages are just like schematics. You can > do whatever you want. You have to do everything, or at least everything > you want to end up in the wire list. From your original post I thought you were saying that there were some unique advantages to HLL generators and also some unique disadvantages. I understand some advantages. Text is easier to version control and be able to document changes. Often the history of changes is as important in documenting a design as the code itself. As you say, it can be more compact than a drawing than a bunch of large blocks with lable and lines showing conections. But I don't know that this is a big issue in an FPGA design. Typically this only happens at the very top level of an FPGA design. It is largely mitigated in schematic by the use of busses for data path designs. > If you are a programmer, writing code in a familiar language may be > easier than using schematics. You can use grep and friends on your > source text. > > One potential disadvantage with text systems is that some technicians > don't like them. That might be true if you are doing board level documentation, but why would a technician be using internal FPGA documentation? What type of work is the technician doing? > I've never worked with a commercial schematic package. I have looked > at a lot of drawings that I consider pretty ugly. Why should I use > a schematic to describe the mapping from signal name to pin number? > Especially when the box is so tall that it wraps over several sheets. > It's just a pile of text. I'd rather use my choice of text editor. The schematic packages are not hard to use once you get used to them. But random logic is a pain since you have to use gates. It is much easier to describe in text using any HLL/HDL. > I don't understand the synthesis path yet. Using synthesis is much like using a C compilier from the early 80's. You never know what code/gates you will get until you try it and look at the results (assembly lang/gates). It can be a real pain trying to figure out how to get it to do what you want without using native code/instantiation. If you switch from one brand of compilier to another you will get very different results and may even get a program/design which won't work! You will also have to rewrite your code if you switch to a different target chip. -- Rick 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23859
Hi,
Your arguments correspond to the JTAG technologies documentation.
On the whole you may be right. But there are some other things
which should be taken into consideration:
*) minimum number of test vectors
*) fault coverage
*) inserting failures on the board directly is difficult and not healthy
for the board
> Also, I don't see where it is very
> useful to run a test simulation when you can normally run the test on a
> real board much faster.
The simulation is useful to verify the test itself. It is difficult to
measure
on the board. Also inserting failures to see if the test does detect
the failure is difficult. On the other side simulation would be the first
step to do a "fault coverage analysis."
> On the lowest level, you generate test vectors that can be used to
> verify that a given output of a JTAG chip is connected to a given input
> of a JTAG chip and no other JTAG chip inputs or outputs. In other words
> I see this as a net test. One way to do this is to output all 0's except
> for one output which is at a 1. Verify that the connected inputs are 1's
> and all other inputs are 0's. Change the stimulus so that a different
> output is at a 1 and repeat until all outputs are verified as 1's while
> all others are at 0. Then repeat this test for all 1's except for a
> single 0 output.
Yes, I am with you. But this implies a lot of test vectors which should be
verified.
> This is my spin on it. I have not seen much in the way of software to
> support this other than the stuff from JTAG Technologies and one or two
> others. None of these companies seem interested enough in my business to
> respond to my enquiries and don't really explain how or what their
> software does on their web site. So I have to treat them as not having a
> product until they show me differently.
I fear your right.
> Are there any share/freeware/open source tools out there for building
> board level test patterns?
Thatīs a very good question. I have only found related thinks.
Some academic tools like "ifsim" and "faultsim" and a lot of VHDL
simulators.
http://gd.tuwien.ac.at:8050/Z/1/
Most of them as C source code. But I was to busy to study them.
Please let me know if you find some other interesting software.
--
Institut fuer Hochenegiephysik
Nikolsdorfer Gasse 18
1050 Wien
Austria
Tel: (+43-1)5447328/50
Article: 23860In article <39648C8B.B92714AE@sqf.hp.com>, Nial Stewart <nials@sqf.hp.com> writes: >I've been interested in evaluating the free versions of Leonardo >and FPGA Express that Alera have been promising for the >last few months and so have been keeping an eye on their >web site. > >Initially this was announced early this year as being >"available in May". Nothing happened, there was no sign >of any software then mid May the text mysteriously changed >to "available in June". It's not approaching mid July >guess what ..... > > >What's going on Altera? Why the promises and no delivery? I doubt if you'll get any answers here. I don't think any one at Altera's allowed to read USENET! > > > >Nial Stewart. -- Regards, Brent Hayhoe. Nortel Networks plc, Tel: +44 (0)1279-402937 Harlow Laboratories, London Road, Fax: +44 (0)1279-403930 Harlow, Essex, CM17 9NA, U.K. Email: hayhoe@nortelnetworks.comArticle: 23861
--------------95A9ED019ACEBEDD7DC0D5EB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Everybody, I am going to design a pci board using the Xilinx' PCI LogiCore. First I want to simulate the design example Ping provided by Xilinx. By running the functional simulation testbench provided by Xilinx the signals behaviors not correct. Does anybody have done this exercise? Where can I get a sample waveform so that I can compare it with mine? Thanks Daning -- ------------------------------------------------------------ Daning Ren | e-mail: daning.ren@stest.ch Switching Test Solutions AG | www : http://www.stest.com Friesenbergstr. 75 | Phone : +41 1 454-6671 CH-8055 Zurich | FAX : +41 1 454-6605 ------------------------------------------------------------ --------------95A9ED019ACEBEDD7DC0D5EB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Hello Everybody, <p>I am going to design a pci board using the Xilinx' PCI LogiCore. First I want to simulate the design example Ping provided by Xilinx. By running the functional simulation testbench provided by Xilinx the signals behaviors not correct. Does anybody have done this exercise? Where can I get a sample waveform so that I can compare it with mine? <p>Thanks <br>Daning <pre>-- ------------------------------------------------------------ Daning Ren | e-mail: daning.ren@stest.ch Switching Test Solutions AG | www : <A HREF="http://www.stest.com">http://www.stest.com</A> Friesenbergstr. 75 | Phone : +41 1 454-6671 CH-8055 Zurich | FAX : +41 1 454-6605 ------------------------------------------------------------</pre> </html> --------------95A9ED019ACEBEDD7DC0D5EB--Article: 23862
Hi Rick,
rickman wrote:
> This is a subject I am very interested in since I wish to do board level
> testing using JTAG and boundry scan.
I originally sent my response directly to Franz since I wasn't sure whether
comp.arch.fpga is an appropriate NG for this topic. On the other hand, if a
few persons are interested on the subject and I can insert the word "FPGA"
somewhere, why not...
> I don't think you need to do
> simulate your test vectors since normally the JTAG chips are not
> functional while you do the testing.
That's only partially true. Some chips are designed so that performing an
EXTEST will always apply "safe" values to the inputs of the JTAG components
(after they have sensed the value on the net), while others (XC4K FPGAs, for
instance) rely on the test pattern generation (TPG) software for this. The
default behavior of the TPG s/w is usually to leave the input data "as is",
i.e. the test patterns make their way to the internal FPGA logic; if needed,
all incoming data can be "masked" to something safer.
In addition, since it is possible to bypass the boundary-scan cell (BSC) of a
global clock in XC4K devices, an active or freerunning clock will clock in
the test pattern values. It is thus the responsability of the test
designer/engineer to ensure the design is OK or else to adapt the test
patterns consequently. To be fair, this feature also has the advantage of
allowing internal (INTEST) functionality tests.
> I see this as a net test. One way to do this is to output all 0's except
> for one output which is at a 1. Verify that the connected inputs are 1's
> and all other inputs are 0's. Change the stimulus so that a different
> output is at a 1 and repeat until all outputs are verified as 1's while
> all others are at 0. Then repeat this test for all 1's except for a
> single 0 output.
Yes, this is the "walking-1/0" test. The JTAG Technologies s/w will do it,
however this kind of test may become quite large since you'll need a minimum
number of test vectors equal to 2x the number of nets you have (or output
pins, if you perform the test using all possible outputs on a given net).
Multiply this by the total number of BSCs you have on your board to get a
first estimation of the number of bits to shift.
There are short sequences that can be generated to simply ensure that after
the test, each net was at a given logic value while the others were (spread
on different vectors) at another value. You thus get a much smaller number of
test vectors (in the order of log2(N), where N is the number of nets).
Regards,
Etienne.
--
______ ______
*****/ ____// _ \_\*************************************************
* / /_/_ / /_/ / / Etienne Racine, Hardware Designer *
* / ____// __ /_/ Visual Systems Engineering *
* / /_/_ / / /\ \ \ CAE Electronics Ltd. *
*/_____//_/_/**\_\_\*************************************************
Article: 23863
You can use the DFFE primitive, which has a clock enable input.
Ex: VARIABLE y_count[7..0] : DFFE;
....
x_count[].ena = y_count[].q;
PS.
'X' is a reserved keyword, so you must call the counter something else...
-Nikolay
"Michael Hopey" <mhopey@hotmail.com> wrote in message
news:3969F88C.7FD16E5C@hotmail.com...
> Hello,
>
> I am using AHDL to describe two counters (call them counter x and
> counter y).
> I need to trigger counter y after counter x has counted a certain number
> of cycles.
> Both counters have the same GLOBAL clock. How can I trigger counter y
> in AHDL ? The algorithm that I am using right now basically counts a
> certain
> number of cycles and then sets an enable output that feeds into counter
> y.
>
> Any help would greatly be appreciated.
>
> Thanks
> Mike
>
>
>
Article: 23864"Brent A. Hayhoe" wrote: > > In article <39648C8B.B92714AE@sqf.hp.com>, Nial Stewart <nials@sqf.hp.com> writes: > >I've been interested in evaluating the free versions of Leonardo > >and FPGA Express that Alera have been promising for the > >last few months and so have been keeping an eye on their > >web site. > > > >Initially this was announced early this year as being > >"available in May". Nothing happened, there was no sign > >of any software then mid May the text mysteriously changed > >to "available in June". It's not approaching mid July > >guess what ..... > > > > > >What's going on Altera? Why the promises and no delivery? > > I doubt if you'll get any answers here. > > I don't think any one at Altera's allowed to read USENET! Yo Brent! I've always been very impressed with the support given here by Peter Alfke for Xilnx. I'm sure if I was new to the field and was trying to decide between Altera and Xilinx devices this would go quite a way to swaying my decision. Nial.Article: 23865
Hi, rick. This is in reponse to the JTAG-related discussion on comp.arch.fpga. I haven't figured out a news server I can post to from work yet, so can you post this to the news group? Also, can you make sure my email address isn't in the post, so I'm not Spammable? Thanks. -Kent -Start-------------------- I'm far from a JTAG Expert, but I"ll try to comment as best I can. I looked at the JTAG technologies stuff a little while ago, but went with a (less expensive) competitor, but from what I could tell, the basics are the same, so here goes. > Franz Hollerer wrote: > > I have to automate board level tests with tools from JTAG technologies. > > The documentation gives an overview. But I don't exactly know how to > > start. I miss the "big idea". First step: "Describe your JTAG chain". this is done by feeding in "BSDL" (Boundary scan Description Language) files into the software from JTAG Tech. These files describe how each of your devices work from he JTAG point of view, such as number of pins, which are in/out/inout, the registers inside the chip's JTAG Controller, etc. These files should be available from each chip's manufacturer. 2nd step: Start doing test patterns. Usually the first test pattern is a pattern that checks that your JTAG chain is actually put together right. I found that getting that one going is about 50% of the work. 3rd step: Create the test patterns for whatever you want to test, such as IC interconnections, etc. 4th Step: Debug. (See below.) 5th Step: Pass it on to production where they use it to test each board coming down the procudtion line. As for using it for development debugging, . . . I've never done that. but there are software packages available that should let you. but I figure that they wouldn't be that useful, because compared to the speed that your circuit is running at, JTAG is S l o w. > > Questions: > > 1) How can I test the test vectors. Is it possible to simulate the test > > and different failures? Assuming you're using JTAG to test the PCB's on the manufacturing line (As opposed to doing something fancy with it inside the FPGA), then I suggest completely debugging a board the Olde Fashioned Way, and then using that board to debug your test vectors. Then, you can break your board (tying pins to ground, or whatever) tomake sure that your test vectors really catch the problem. > > 2) JTAG Technologies uses a Boundary-scan Test Specification Language > > (BTSL). I believe that this is a proprietary solution, isn't it? I haven't heard of it, but I would guess that's it's basically a scripting language that contains all the tet vectors. If I remember correctly, JTAG Technologies has a "Test Pattern Generator" that you can use to help you generate the Test Patterns. I beleive that you feed it the netlist file, and it figures out what is connected to what. It can also help you do fancy things like "Cluster tests" (That's where you have some logic link and gates, or gats, lathes, etc.), and Read-Write memory tests. If it's the same as the company that I'm using (Corelis), then the have already written little macros that describe the clock/control signal required for different SRAM/DRAM chips. You can also use it to program/test flash, but I've never done that. > > 3) I would like to write the tests in VHDL and simulate them. Would it > > be possible to create BTSL files (application data file .apl, general data file > > .gen, ...) for the JTAG tools from this VHDL source? Umm. I have no idea. But ... why? It would be much, much easier to debug the board, and then use a "working board" to debug the JTAG. rickman wrote: > On the lowest level, you generate test vectors that can be used to > verify that a given output of a JTAG chip is connected to a given input > of a JTAG chip and no other JTAG chip inputs or outputs. In other words > I see this as a net test. One way to do this is to output all 0's except > for one output which is at a 1. Verify that the connected inputs are 1's > and all other inputs are 0's. Change the stimulus so that a different > output is at a 1 and repeat until all outputs are verified as 1's while > all others are at 0. Then repeat this test for all 1's except for a > single 0 output. > > At the next level, you need to test other, non-JTAG componenets such as > memory, buffers/registers and anything else that you have on the board. > This must be done ad-hoc as each component dictates how it is to be > tested. I agree with the ideas here, except that the JTAG software will automatically generate the tests with a single '1' or a sngle '0' wandering across your pins. I'd suggest letting the software do it, 'cause I figure they've done research into what test test 100% of faults with minimum of time, and stuff like that. Also, the software can help you ou with the memories and stuff .. don't necessarily need to do it "ad hoc". If you have something non-standard, you will probably have to do it by hand. > If you have test connections to the board IO connectors, you can test > these as well. We've thrown together an "adapter" that loops back JTAG connected pins on the connector to other JTAG connected pins on the connector, so that we've tested all the pins on the connector . . . And . . if I'm not mistaken, it's not too difficult to hire an outside company (Ask JTAG Tech.) to develp the test vectors for you. We found that we could have our company do our first two projects themselves, (I get to push the button and seeif it turns green or red) for less than it would cost to buy the Test Pattern Generation Software. And, that's managed to give me a feel for how it works and what it's capable of without paying *too* much. -Kent ------------ Kent Orthner Furukawa ElectricArticle: 23866
Franz Hollerer wrote: > > Hi, > > Your arguments correspond to the JTAG technologies documentation. > On the whole you may be right. But there are some other things > which should be taken into consideration: > > *) minimum number of test vectors > *) fault coverage > *) inserting failures on the board directly is difficult and not healthy > for the board > > > Also, I don't see where it is very > > useful to run a test simulation when you can normally run the test on a > > real board much faster. > > The simulation is useful to verify the test itself. It is difficult to > measure > on the board. Also inserting failures to see if the test does detect > the failure is difficult. On the other side simulation would be the first > step to do a "fault coverage analysis." I don't see where this is really true. I don't know how you would do a "fault coverage analysis" in VHDL. I also don't see how you could even verify that a given fault is detected in the simulation. The faults on a real board are physical and are likely not to correspond to the "logical" faults you would introduce into your simulation. Shorted wires, for example, may or may not cause a "stuck at" fault behavior. I guess I see the vector generation and fault coverage analysis to be things that are fairly simple to do by hand for a board level test. Of course, our boards are PC/104 and so are not very complex. > Yes, I am with you. But this implies a lot of test vectors which should be > verified. Can you explain how you would verify the test vectors? How do you introduce your simulated faults and what type of faults do you simulate? -- Rick 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 23867
"Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message news:396C9BA2.8B4D04F2@flukenetworks.com... > Jan Gray wrote: > > HLL synthesis, I'm ambivalent about. I hate wasting hardware, but I > > understand others are more sanguine about that. > > I don't like wasting gates and flops either, > even though they aren't very expensive anymore. > What I do like is finishing on time and > knowing the thing is going to work as well as > the simulation. ... > Apparently you haven't tried Exemplar. > No pragmas. Just code. Forgive me for not defining my terms better. Here I was speaking to HLL synthesis, e.g. inferring hardware from code written in high level languages (Java/C++), not HDL synthesis, e.g. inferring hardware from behavioral Verilog/VHDL. For my own cores have also voted with my feet for "careful Verilog" + floorplanning, from schematics. Schematics (Foundation ones anyway) do not enable easy sharing of excerpts nor version control. Fatal flaws. I define "careful Verilog" as the pushing-on-a-rope process of deciding what device primitives should implement my datapath, and then writing and rewriting my Verilog and reviewing the emitted netlists until the darn synthesis tool emits approximately what I expect it to, and then applying a floorplan through various techniques like UCF generators (in lieu of FMAP support in FPGA Express at the time (www.fpgacpu.org/usenet/rope_pushing.html)). Careful Verilog is especially important in datapaths -- in contrast, "laissez faire Verilog" may be "good enough" for control unit. "Trust, but verify." "Whatever." Using this technique I was able to move my schematics-based XSOC/xr16 design to a synthesizable Verilog model with negligible area penalty, e.g. still fits in an XC4005XL. Here is a comparison of the two versions that I did at the time: " What Sch'c Verilog ---- ----- ------- Cycle time 41 53 ns Freq 24.5 18.9 MHz Flops 252 252 4LUTs 263 288 ROMs 21 0 Total FGs 284 288 3LUTs 40 48 RAMs 64 64 TBUFs 152 152 P&R time 5'45" 8'52" Commentary: here, the Verilog doesn't fare too badly. 25% slower, approximately the same area. Of course, I took great care in coding the Verilog, examining the output to make sure no extraneous logic was introduced, and applied as much floorplanning as was practical (e.g. registers and RAMs). " Jan Gray Gray Research LLCArticle: 23868
This is a multi-part message in MIME format. --------------55F85526D4E78DC75201FDDC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi , How a configuration Cache can provide a faster reconfiguration ?. Is there Anyone has achieved faster reconfiguration in this technique. I would like to know more about this technique. kamal --------------55F85526D4E78DC75201FDDC Content-Type: text/x-vcard; charset=us-ascii; name="raja.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for kamal Content-Disposition: attachment; filename="raja.vcf" begin:vcard n:;kamal raja tel;home:1/240,carmody road , st lucia , australia tel;work:Computer science and electrical engineering x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:raja@elec.uq.edu.au fn:kamal raja end:vcard --------------55F85526D4E78DC75201FDDC--Article: 23869
By my reckoning, a XC2S150 part from Xilinx has about a million bits of configuration data, and the Xilinx serial proms support a 10 MHz bit rate. Does that mean that it takes about 100ms to have valid outputs after power up? That would be OK for my application, but if it took much more than that I could run into some problems... -- Gary Watson gary@nexsan.sex (Change dot sex to dot com to reply!!!) Nexsan Technologies Ltd. Derby DE21 7BF ENGLAND http://www.nexsan.comArticle: 23870
Hi Daning, What do you feel is incorrect in the behavior of the design example and testbench? As far as I am aware, it is correct -- and if there is a bug in it, I'd love to hear what it is so I can file a change request and fix it. Thanks, Eric Crabill Daning Ren / 30066 wrote: > > Hello Everybody, > > I am going to design a pci board using the Xilinx' PCI LogiCore. First > I want to simulate the design example Ping provided by Xilinx. By > running the functional simulation testbench provided by Xilinx the > signals behaviors not correct. Does anybody have done this exercise? > Where can I get a sample waveform so that I can compare it with mine? > > Thanks > Daning > > ------------------------------------------------------------ > Daning Ren | e-mail: daning.ren@stest.ch > Switching Test Solutions AG | www : http://www.stest.com > Friesenbergstr. 75 | Phone : +41 1 454-6671 > CH-8055 Zurich | FAX : +41 1 454-6605 > ------------------------------------------------------------Article: 23871
Typical design flow also includes "static" timing analysis after place and route. Synopsys PrimeTime for example will calculate delays for each path to/from/between registers and report paths that don't meet the cycletime or other constraints that you define. This avoids having to inspect timing of internal node between functional rtl and post synthesis/P&R netlists. You can preserve node names by ensuring that they exist as a port name on a sub module and assuming that you DONT flatten the hierarchy during synthesis. I don't know that they can be preserved through the maxplus P & R portion. Maxplus also has a static analysis tool but only reports cycle time achievable after P & R and reports raw path times, it won't check against a set of constraints... I believe it will generate an netlist w/SDF file (SDF contains timing info to annotate the netlist) that Synopsys PrimeTime will consume.. <khanzode@yahoo.com> wrote in message news:8kftg7$3gv$1@nnrp1.deja.com... > Hi, > > We have recently started desinging using Verilog and I have a question > regarding the timing simulation. Altera FPGAs (10KE series) is used for > the most part. > > The design flow is as follows: > > 1. Write code in Verilog > > 2. Functional simulation using VCS > (Synopsys Verion 5.1NT running on an NT workstation) > > 3. Synthesis using Synplify. > > 5. Place and route using Max+PlusII 9.6 > > I have not been able to perform the full chip timing simulations very > effectively. > > After synthesis, Synplify changes a _lot_ of internal nodenames and I > have not found a way to observe the timing between some of these > signals. Is there a way this can be performed with the above set of > tools? I would appreciate any help from someone who has used the .vo > file generated by Max+Plus II for timing simulation of the whole design. > > I am running into situations where the functional simulations (with > phantom delays in combinational statements) are fine, but the > synthesized design doesnot work on the bench. I also need the timing > simulation to accurately estimate the top speed of the design. > > Thanks, > > -- Vivek > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 23872
In article <3969D673.573FE3B5@voila.fr>, christelle <van-den- broucke@voila.fr> writes >Hi all, > >Is there anyone using Quartus? >I've heard that there are lots of problems with this tool... > In my experience, don't bother with a UNIX ported version (Ultra 60 - 700Mbytes RAM) - it's the only program that I've known to core dump on a regular basis :( Quartus appears to run well on a 900MHz PC with 1 Gbyte of RAM. Anything less and again I have found it to be painfully slow and, more serious, prone to various unexplained error messages/crashes. I'm currently attempting to fit a 400k gate equivalent design with 380 I/O pins into the APEX 20KE600 device. It appears have gone in and met timing but it will be a two/three weeks before I can establish if the post fitting simulations work as expected. -- Alan mailto:news4me@amacleod.clara.co.ukArticle: 23873
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:396D27A4.E1EFDCC0@yahoo.com... > This is a subject I am very interested in since I wish to do board level > testing using JTAG and boundry scan. I don't think you need to do > simulate your test vectors since normally the JTAG chips are not > functional while you do the testing. Also, I don't see where it is very > useful to run a test simulation when you can normally run the test on a > real board much faster. But if your tests are well-considered, it should be quite easy to pinpoint the error, which isn't the case if a microprocessor or FPGA or CPLD doesn't start (for example). > My understanding of how to do board level testing using boundry scan is > to think of all the JTAG chips as empty boxes with boundry scan shift > registers connected to the IO pins. The goal of this testing is to test > the board, the connections to the board and the remaining components > (non-JTAG) on the board. This is done with knowledge of how the chips > are wired together. Agree > On the lowest level, you generate test vectors that can be used to > verify that a given output of a JTAG chip is connected to a given input > of a JTAG chip and no other JTAG chip inputs or outputs. In other words > I see this as a net test. One way to do this is to output all 0's except > for one output which is at a 1. Verify that the connected inputs are 1's > and all other inputs are 0's. Change the stimulus so that a different > output is at a 1 and repeat until all outputs are verified as 1's while > all others are at 0. Then repeat this test for all 1's except for a > single 0 output. I don't think this is much applicable ; a lot of pins are still connected to other elements, which makes low level a dangerous path to walk (I remember not thinking of the wise use of OE, RD and WR ;-)) Making such tests is good to detect if a board is good, and certainly can be used if the board must be rejected if there are errors, if the board gets more expensive and rejection isn't an option, you better start with tests that are already to isolate errors, which make reparations easier. Even if BoundaryScan is slow, a scan more or less doesn't matter that much then. Most of the test time gets lost with the user interface which is much slower. My first program I wrote 'in Boundary Scan' took more than 1 minute, but it tested nearly completelly a complex board (over 3000 DR-scans, using 9 Boundary Scan elements). We work with HW&SW from Asset Technologies, but as it's overqualified, we are starting to make a low cost thing for ourselves (using the parallel port, and some procedures under HP VEE - what we use for other purposes already). It's starting to work, but for long chains with several (or a lot of) elements, we still must think of a good way to work this way. HTH, AlainArticle: 23874
100 mS seems to be correct if you are using the serial programming modes, but check out pages 17-20 in the SpartanII data sheet. The slave parallel mode is much faster at 50 MHz CCLK with no waiting and 8 bits being writen per CCLK edge! This will load your XC2S150 in as little as 2.5 mS if your configuration logic can keep up. The only question I have in using this mode is whether the CS and WRITE signals may be deasserted between CCLK edges. They make it clear that you can cause a programming abort by not doing this properly, I don't think they make it clear as to what the required procedure is. I copied this from the new, *unlocked* Spartan II datasheet! "For the present example, the user holds WRITE and CS Low throughout the sequence of write operations. Note that when CS is asserted on successive CCLKs, WRITE must remain either asserted or de-asserted. Otherwise an abort will be initiated, as in the next section." I assume that they are saying if you clock CCLK with CS asserted, you had better not do a READ as opposed to a WRITE??? Or are they saying that you have to keep CS and WRITE asserted at all times once you start to program the chip? I had this exact same confusion with the way a similar mode in the Lucent FPGAs was described. I am also not clear about the use of the term "packets" on pages 18-19. "When using the Slave Parallel Mode, write operations send packets of byte-wide configuration data into the FPGA." In the abort section, they say you have to resync after an abort using a "new synchronization word" before sending new packets. What does this mean? What are packets? I don't plan to abort configuration loading, but I would like to understand this. Gary Watson wrote: > > By my reckoning, a XC2S150 part from Xilinx has about a million bits of > configuration data, and the Xilinx serial proms support a 10 MHz bit rate. > Does that mean that it takes about 100ms to have valid outputs after power > up? That would be OK for my application, but if it took much more than that > I could run into some problems... > > -- > > Gary Watson > gary@nexsan.sex (Change dot sex to dot com to reply!!!) > Nexsan Technologies Ltd. > Derby DE21 7BF ENGLAND > http://www.nexsan.com -- Rick 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com
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