Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 38850

Article: 38850
Subject: Re: Coregen Half-Band FIR filter implemenation does not work
From: yuryws@optonline.com (Yury)
Date: 26 Jan 2002 10:55:32 -0800
Links: << >>  << T >>  << A >>
"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?

-- Yury

Article: 38851
Subject: Re: Synthesis Tools for Xilinx
From: Kevin Brace <ihatespamkevinbraceusenet@ihatespamhotmail.com>
Date: Sat, 26 Jan 2002 13:06:17 -0600
Links: << >>  << T >>  << A >>
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: 38852
Subject: Re: MSP430 + Xilinx via JTAG
From: "DG_1" <dgacina@san.rr.com_no.spam>
Date: Sat, 26 Jan 2002 19:54:10 GMT
Links: << >>  << T >>  << A >>
Hi 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.spam





Article: 38853
Subject: New Risc5x cpu core on Opencores
From: "Mike Johnson" <mikej<NOSPAM>opencores.org>
Date: Sat, 26 Jan 2002 20:23:23 -0000
Links: << >>  << T >>  << A >>
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.org



Article: 38854
Subject: Re: Homebrew computers using FPGA?
From: Franck Pissotte <franck.pissotte@free.fr>
Date: Sat, 26 Jan 2002 22:04:39 +0100
Links: << >>  << T >>  << A >>
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 revues



Article: 38855
Subject: Re: Homebrew computers using FPGA?
From: Franck Pissotte <franck.pissotte@free.fr>
Date: Sat, 26 Jan 2002 22:16:08 +0100
Links: << >>  << T >>  << A >>
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 revues



Article: 38856
Subject: Re: MSP430 + Xilinx via JTAG
From: "Matti Ruusunen" <mattir@welho.dot.com>
Date: Sat, 26 Jan 2002 23:16:22 +0200
Links: << >>  << T >>  << A >>

"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




Article: 38857
Subject: Problem with Altera programmer
From: Marcin E. Hamerla <mehamerla@pro.onet.pl>
Date: Sat, 26 Jan 2002 23:19:32 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: Problem with Altera programmer
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Sat, 26 Jan 2002 22:21:39 -0000
Links: << >>  << T >>  << A >>
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
Subject: Re: Synthsis Tools for Xilinx
From: "Matt Bielstein" <bielstein@attbi.com>
Date: Sat, 26 Jan 2002 22:53:56 GMT
Links: << >>  << T >>  << A >>
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
Subject: tri-state vs. Mux
From: "Josh Pfrimmer" <yeah_spam_me@thisaddress.com>
Date: Sat, 26 Jan 2002 15:33:44 -0800
Links: << >>  << T >>  << A >>
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: 38861
Subject: Re: Xilinx webpack
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Sun, 27 Jan 2002 00:32:45 GMT
Links: << >>  << T >>  << A >>


Falk 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
Subject: Re: Problem with Altera programmer
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Sun, 27 Jan 2002 00:37:17 GMT
Links: << >>  << T >>  << A >>


"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
Subject: Re: Xilinx webpack
From: Kevin Brace <ihatespamkevinbraceusenet@ihatespamhotmail.com>
Date: Sat, 26 Jan 2002 19:24:12 -0600
Links: << >>  << T >>  << A >>
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: 38864
Subject: Re: tri-state vs. Mux
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 27 Jan 2002 01:35:50 GMT
Links: << >>  << T >>  << A >>
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


Article: 38865
Subject: Re: Xilinx webpack
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 27 Jan 2002 02:00:11 GMT
Links: << >>  << T >>  << A >>


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 Applications



Article: 38866
Subject: Re: Xilinx PCI logicore: clarification on nature of COMPLETE
From: David Miller <spam@quartz.net.nz>
Date: Sun, 27 Jan 2002 16:17:04 +1300
Links: << >>  << T >>  << A >>
 > 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 Aurelius


Article: 38867
Subject: Re: New Risc5x cpu core on Opencores
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Sun, 27 Jan 2002 03:32:32 GMT
Links: << >>  << T >>  << A >>
"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  USA



Article: 38868
Subject: Re: tri-state vs. Mux
From: David Miller <spam@quartz.net.nz>
Date: Sun, 27 Jan 2002 16:33:05 +1300
Links: << >>  << T >>  << A >>
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 Aurelius


Article: 38869
Subject: Re: Xilinx PCI logicore: clarification on nature of COMPLETE
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Sat, 26 Jan 2002 21:02:45 -0800
Links: << >>  << T >>  << A >>

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 Aurelius

Article: 38870
Subject: Re: Coregen Half-Band FIR filter implemenation does not work
From: newman5382@aol.com (newman)
Date: 26 Jan 2002 21:56:49 -0800
Links: << >>  << T >>  << A >>
> 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.  

Newman

Article: 38871
Subject: Re: tri-state vs. Mux
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 27 Jan 2002 01:15:38 -0500
Links: << >>  << T >>  << A >>
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 FAX

Article: 38872
Subject: Re: MSP430 + Xilinx via JTAG
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 27 Jan 2002 01:17:51 -0500
Links: << >>  << T >>  << A >>
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 FAX

Article: 38873
Subject: Re: tri-state vs. Mux
From: "Josh Pfrimmer" <yeah_spam_me@thisaddress.com>
Date: Sat, 26 Jan 2002 22:27:42 -0800
Links: << >>  << T >>  << A >>
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 FAX



Article: 38874
Subject: Re: MSP430 + Xilinx via JTAG
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 27 Jan 2002 01:47:02 -0500
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search