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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 105400

Article: 105400
Subject: HW Debug tools
From: Rube Bumpkin <Someone@somewhere.world>
Date: Fri, 21 Jul 2006 15:01:17 -0400
Links: << >>  << T >>  << A >>
Has anyone used any of the HW debug tools that are available for use 
with a logic analyzer? I'm talking about the FPGAView tool from First 
Silicon Solutions for the Tek analyzer, or the Dynamic probe from Agilent.

I'm starting a new project, and have no analyzer. Some groups in the 
company are using Altera, some are using Xilinx. I'm reasonably neutral.

Do you have any horror stories or successes? Any thoughts?

RB

Article: 105401
Subject: Re: Virtex 4 ACE Compact Flash configuration problem
From: "EEngineer" <maricic@gmail.com>
Date: 21 Jul 2006 12:19:16 -0700
Links: << >>  << T >>  << A >>
I started from the beginning and followed all the steps you suggested.
The result was the same - the red led was on and the green 'done' was
off.

Then I downloaded the mkdosfs and formatted the CF card as per answer
record you recommended. Same result - 'Err' was on again. I have
noticed that CF has decreased from 32MB to 24MB after formatting. I
tested if the old demo ACE files worked - copied them back from the HDD
to the card, they worked fine again, just not the new one created with
iMPACT.
What is the ACE file size that you created? All the demos are 1686KB
and the new ACE created with iMPACT is 1674KB.

I tried with just single ACE file on the CF, any of the demo files
worked that way too, but not the new one. Also didn't work with the
file structure generated by iMPACT:

E:\my_ml402\rev0\rev0.ace
E:\xilinx.sys

I always had CFG ADDR switches set to 000111, and SW12 to SYS ACE
position.

Thanks for help.
Dan

Ed McGettigan wrote:
> EEngineer wrote:
> > I have changed the order:
> >
> >  Device #0 was xcf32p
> >  Device #1 xc4vsx35
> >  Device #2 xc95144lx
> >
> > Assigned the configuration bit file again to the xc4vsx35 device,
> > generated ACE, put it on CF, again could not configure the board.
> >
>
> I just went ahead and generated a new
ML402 ACE file using 8.1i and
> copy the files to the CF card with no issue or doing anything outside
> of the flow (such as SVF edits that you have been mentioning).
>
> Try the following.
>
>   1) Start over with a new iMPACT System ACE project
>   2) Call the "Collection" name "my_ml402"
>   3) Only create one revision (rev0)
>   4) Set up the device chain as above XCF32P -> XC4VSX35 -> XC95144XL
>   5) Assign your 4VSX35 BIT file to the XC4VSX35 device
>   6) Generate the System ACE file with no other edits
>   7) Remove all of the files from your CF card
>   8) Copy just the single ACE that you just generated to the CF card
>   9) Insert the CF card in the ML402
> 10) Verify that SW12 is set to the SYSACE position
>
> If this works then you have a good ACE file.  If it doesn't work go
> back and double check that you really have the correct chain defined
> and that your bitstream is targeting a SX35 device and that you generate
> the BIT file with the startupclk = jtagclk setting.
>
> If you can't get a CF card with just an ACE file to work then you
> probably have a mal-formated CF Card see this answer record to reformat
> the card: http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=14456
>
> Now that the ACE file is known to be good. You either have an address
> switch setting issue or you copied the files incorrect to the CF card.
>
> 1) Remove all of the files from the CF card again
> 2) Copy the xilinx.sys and the "my_ml402" collection directory that you
>     generated earlier to the blank CF card.
> 3) Verify that the CFG ADDR switches 1, 2 & 3 are in the OFF state for
>     an address of 000
> 4) Insert the CF Card in the ML402
> 5) The ACE file should now load
> 
> 
> Ed McGettigan
> --
> Xilinx Inc.


Article: 105402
Subject: Re: Hardware book like "Code Complete"?
From: "Tommy Thorn" <tommy.thorn@gmail.com>
Date: 21 Jul 2006 12:26:49 -0700
Links: << >>  << T >>  << A >>
Andy wrote:
> Too bad the author is a proponent of the ancient style of separate
> clocked and combinatorial processes in VHDL. He even uses a third
> process for registered outputs.
>
> I think he needs to discover what variables can do for you in a clocked
> process.

Really?  Which of his arguments do you disagree with?

I always thought of the two-process style as being redundant, but after
reading Dr. Chu's argument, I'm revising my thinking.  For one thing,
this style makes it much less disruptive to change a Moore output to a
Mealy and vise versa.

My thanks to S.C. for the reference.  Good one.

Tommy


Article: 105403
Subject: Re: Last Chance for Tarfessock1 Features
From: "John Adair" <g1@enterpoint.co.uk>
Date: 21 Jul 2006 12:35:36 -0700
Links: << >>  << T >>  << A >>
All of our development boards support LVDS with matched pair routing.
Even our low cost Raggedstone has about 50+ pairs of signals usually
matched in length 1mm or less that run together from the relevant pair
on the FPGA to the DIL headers. They don't share with other things
generally either. This is part of the reason we use large I/O count
devices even on our cheap boards. It is a major differentiation between
our product and something like the Spartan-3 and 3E starter kits that
use relatively small I/O count devices. We also tend use the large size
package because of the SSO advantage and in fact we have an internal
production test for some the boards with a very large percentage of
I/O, at large toggle rate, running over our boards at 50Mhz and we get
very good performance. Conversely we have seen other peoples designs
that use PQFP and TQFP packages having very serious issues with small
percentage toggle rates at relative low frequencies and the advantage
of a BGA package is very large and well worth the little bit of extra
money to have in most design cases.

Tarfessock1 will have support for LVDS built in a good percentage of
the I/O if not all, I expect we will have 20+ pairs maybe even the lot
to give 35 pairs. The grounding we will have to see how good it is and
whether virtual grounds from FPGA I/Os are needed. However we do want
to maintain the planned 70 I/O as it is fairly key to what we want to
do outside the card itself. Ultimately whatever we do we won't please
everyone and that is what market choice for. I do think we have formula
that will win a lot of friends especially when the planned extended
functionality becomes clearer in the shape of future add-on modules. I
don't think the price is bad either especially if you qualify for
student pricing but I'm sure someone will still point out the card
costs more than it's constituent parts and designing it is cheap and
not be equated in the price.

John Adair
Enterpoint Ltd.


John_H wrote:
> Not enough grounds is a serious problem for good, high speed design.  If
> there's a decent job done with differential routing for LVDS pairs (and LVDS
> voltage banks) then the demands on the grounds are lighter, allowing both a
> slow-speed, many I/O solution *and* a high-speed solution.  The Spartan3E
> Starter kit had more than a dozen differential pairs but only about 4 pairs
> were "usable" because the others shared signals with LEDs or test headers
> that left huge stubs.  If you did a good job with differential pairs, the
> speed might be pushed through the development connector.
>
> "John Adair" <g1@enterpoint.co.uk> wrote in message
> news:1153470659.303728.303030@75g2000cwc.googlegroups.com...
> > Bob
> >
> > Probably won't be as many as desireable but the option of using virual
> > grounds using switched FPGA I/Os will be possible.  I will also see if
> > we can make any build options to hard ground what are I/O pins via
> > solder bridge or 0201 resistor etc.
> >
> > Generally we could use a few I/O than we have available on the 120 way
> > connector currently pencilled in but the next size up standard
> > connector is 180 way and is a bit big physically for the card edge.
> > Generally we are trying to an internal standard for what might be
> > developed as future products beyond Tarfessock1.
> >
> > If we get a good response to this card it likely we will do a big
> > brother version in Virtex-5 but that is only one of many projects
> > competing for team time in Q4 and not guaranteed to happen as yet.
> >
> > John Adair
> > Enterpoint Ltd.
> >
> > Bob Perlman wrote:
> >> Hi -
> >>
> >> I don't know if anyone else has mentioned it, but please make sure you
> >> have lots of grounds, well spread out, on the external module
> >> connector(s).
> >>
> >> Bob Perlman
> >> Cambrian Design Works
> >> http://www.cambriandesign.com
> >>
> >>
> >> On Thu, 20 Jul 2006 10:48:42 +0100, "John Adair"
> >> <removethisthenleavejea@replacewithcompanyname.co.uk> wrote:
> >>
> >> >We have mentioned Tarfessock1 before and now at the last point where we
> >> >can
> >> >add features for the board. You know have the last chance to ask for
> >> >things
> >> >you might want in this Cardbus format card so do ask. Currently the spec
> >> >on
> >> >the card is as follows:
> >> >
> >> >Dual Spartan-3E (Device 1 notionallly fixed covering Cardbus interface
> >> >etc),
> >> >Device2 programmable from Device1 or SPI prom.
> >> >Device 2 = XC3S1200 or XC3S1600
> >> >4 ch DAC
> >> >8 ch A/D
> >> >O/P JTAG - looks like parallel port + cable3 for programming outside
> >> >target
> >> >boards. Supported by Device1.
> >> >1 serial RS232 interface outside world for MicroBlaze support etc. 1
> >> >internal serial (TTL) also possible to Device2.
> >> >4 ch RS485 serial controllable half duplex.
> >> >SDRAM + second SPI Flash on Device2
> >> >Approx 70 5V tolerant I/O to outside world.
> >> >Switched 3.3V O/P to supported external modules that don't need to be
> >> >powered all the time (i.e. for running in the wild on laptop battery
> >> >etc).
> >> >
> >> >We are using a 120 pin connector to support all these features and there
> >> >will be breakout board/s available to better pitches.
> >> >
> >> >We are currently still on schedule for a September launch.
> >> >
> >> >John Adair
> >> >Enterpoint Ltd. - Soon to be Home of Tarfessock1. The Spartan-3E Cardbus
> >> >Development Board.
> >> >http://www.enterpoint.co.uk
> >> >
> >


Article: 105404
Subject: Re: Hardware book like "Code Complete"?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 21 Jul 2006 12:51:55 -0700
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:

> 
>  Our VHDL and Verilog courses teach language essentials
> and coding style, and discuss some generally-applicable 
> design techniques such as FSMs, but to keep them generic
> (and a reasonable length!) we don't discuss how to design 
> any specific kind of hardware.  But we have often been 
> asked to create a course covering "the art of good RTL 
> design" or somesuch.  What these customers seem
> to want is something like "thirty years of design 
> experience in a three-day class". 

I hear it stated like this:
"I'd like to try that technique, but
 I'm not sure it will work so I'm sticking
 with the way I did it last time."

And that's what many opencores designs
look like.

> It's never been 
> feasible for us to do that, because the exact content 
> would be so specific to the particular needs of any 
> one customer.  But an open, peer-moderated, 
> frequently-updated repository sounds like a good 
> idea to me.  I don't mean a library of complete 
> ready-cooked designs like opencores.org; rather,
> I'm thinking of a collection of "design patterns" 
> and shared experience. 

I imagine a site like opencores
with working synthesis and verification code
under version control. The difference would be
that all of the designs would be peer-reviewed
and make full use of advanced synthesis techniques.
The examples would be easy to read, understand and modify.
They would be simple, but non-trivial.
Working code would provide some confidence for the skeptical.

The same code base would provide the "design patterns"
for tutorial authors to reference and write about.
Designs might be combined structurally or procedurally.
They might be used as benchmarks for synthesis
or for evaluating the latest assertion based testing.

> Any takers?

I would be happy to write and review some code examples,
but we would need to find an interested retired person
to be the web master and chief editor.

    -- Mike Treseler

Article: 105405
Subject: Re: Creating EDIF from Verilog, then using VHDL wrapper
From: "John Adair" <g1@enterpoint.co.uk>
Date: 21 Jul 2006 13:18:52 -0700
Links: << >>  << T >>  << A >>
Robin

Coming from a similar direction is one of our TechiTips here
http://www.enterpoint.co.uk/techitips/Previous_TechiTips/techitips_increment_synth.html.
It is a little bit old now but the module build up approach described
is still applicable to mixed language application.

John Adair
Enterpoint Ltd.

Robin Bruce wrote:
> Hi group, here's a question:
>
> Can I synthesise a component described in Verilog, obtain an EDIF, then
> write a VHDL wrapper around it so as to integrate it into a greater
> VHDL project.
> 
> yours in ignorance,
> 
> Robin


Article: 105406
Subject: Re: HW Debug tools
From: "John Adair" <g1@enterpoint.co.uk>
Date: 21 Jul 2006 13:49:29 -0700
Links: << >>  << T >>  << A >>
One thing worth considering is using logic analyser cores from Xilinx -
Chipscope or Altera - Signaltap themselves alone. If you are on a
tightish budget they are very cost effective and very good. We find we
don't usually need anything more and they are very portable, i.e.
laptop, if you need to work in the field. Downside of thsee tools is
they need resource in the FPGA.  Using one of the hookups to an
external analyser does mean less resource used in the FPGA and that is
generally the only time I would use such an analyser. Even then I would
take the option, if available, of starting with an oversized FPGA to
allow the build in of an analyser function rather than plan to use an
external analyser.

John Adair
Enterpoint Ltd.

Rube Bumpkin wrote:
> Has anyone used any of the HW debug tools that are available for use
> with a logic analyzer? I'm talking about the FPGAView tool from First
> Silicon Solutions for the Tek analyzer, or the Dynamic probe from Agilent.
>
> I'm starting a new project, and have no analyzer. Some groups in the
> company are using Altera, some are using Xilinx. I'm reasonably neutral.
> 
> Do you have any horror stories or successes? Any thoughts?
> 
> RB


Article: 105407
Subject: Re: Last Chance for Tarfessock1 Features
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 21 Jul 2006 21:13:38 GMT
Links: << >>  << T >>  << A >>
"John Adair" <g1@enterpoint.co.uk> wrote:

>Web page with block diagram and outline spec is now on website here
>http://www.enterpoint.co.uk/moelbryn/tarfessock1.html.

How about a programmable clock source? Even better, one which has
equal / matched lines to each FPGA so both FPGAs get the same clock.
Multiple independant frequencies would be better. This may also be a
good selling point for universities, crossing a clock boundary is not
trivial in most cases.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 105408
Subject: Re: Last Chance for Tarfessock1 Features
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 21 Jul 2006 21:57:16 GMT
Links: << >>  << T >>  << A >>
I've had passing interest in your offerings before - they look reasonable 
for the price and functionality offered.  Your discussion about acute 
attention to differential I/O and use of BGA packages is making me think 
more seriously about shipping stuff across the pond.  For Tarfessock1, I'm 
left wondering what needs to be developed by me versus what you would supply 
for CardBus access.  I'm the FPGA guy, not into Windows drivers to save my 
life.

I'll take another, closer look at your site this weekend, particularly the 
info you've generated so far for Tarfessock1.

- John_H


"John Adair" <g1@enterpoint.co.uk> wrote in message 
news:1153510536.728994.136460@75g2000cwc.googlegroups.com...
> All of our development boards support LVDS with matched pair routing.
> Even our low cost Raggedstone has about 50+ pairs of signals usually
> matched in length 1mm or less that run together from the relevant pair
> on the FPGA to the DIL headers. They don't share with other things
> generally either. This is part of the reason we use large I/O count
> devices even on our cheap boards. It is a major differentiation between
> our product and something like the Spartan-3 and 3E starter kits that
> use relatively small I/O count devices. We also tend use the large size
> package because of the SSO advantage and in fact we have an internal
> production test for some the boards with a very large percentage of
> I/O, at large toggle rate, running over our boards at 50Mhz and we get
> very good performance. Conversely we have seen other peoples designs
> that use PQFP and TQFP packages having very serious issues with small
> percentage toggle rates at relative low frequencies and the advantage
> of a BGA package is very large and well worth the little bit of extra
> money to have in most design cases.
>
> Tarfessock1 will have support for LVDS built in a good percentage of
> the I/O if not all, I expect we will have 20+ pairs maybe even the lot
> to give 35 pairs. The grounding we will have to see how good it is and
> whether virtual grounds from FPGA I/Os are needed. However we do want
> to maintain the planned 70 I/O as it is fairly key to what we want to
> do outside the card itself. Ultimately whatever we do we won't please
> everyone and that is what market choice for. I do think we have formula
> that will win a lot of friends especially when the planned extended
> functionality becomes clearer in the shape of future add-on modules. I
> don't think the price is bad either especially if you qualify for
> student pricing but I'm sure someone will still point out the card
> costs more than it's constituent parts and designing it is cheap and
> not be equated in the price.
>
> John Adair
> Enterpoint Ltd. 



Article: 105409
Subject: Re: Last Chance for Tarfessock1 Features
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 21 Jul 2006 22:01:40 GMT
Links: << >>  << T >>  << A >>
I found the IDT5V9885 to be surprisingly cost effective.  Intended to be a 
clock generator rather than a zero delay buffer style of clock regenerator, 
the filtering selections for on-chip filters appear to make the device 
robust enough for serious clock cleanup.  Even spread spectrum is available 
within the one integrated device.  I don't know if I'll get it on the 
prototypes due back within the month (I'm only a contributor, not the 
designer) but I sure would love to work with that part!  External part count 
is low, programmability is high.

"Nico Coesel" <nico@puntnl.niks> wrote in message 
news:44c140f7.1387066536@news.kpnplanet.nl...
> "John Adair" <g1@enterpoint.co.uk> wrote:
>
>>Web page with block diagram and outline spec is now on website here
>>http://www.enterpoint.co.uk/moelbryn/tarfessock1.html.
>
> How about a programmable clock source? Even better, one which has
> equal / matched lines to each FPGA so both FPGAs get the same clock.
> Multiple independant frequencies would be better. This may also be a
> good selling point for universities, crossing a clock boundary is not
> trivial in most cases.
>
> -- 
> Reply to nico@nctdevpuntnl (punt=.)
> Bedrijven en winkels vindt U op www.adresboekje.nl 



Article: 105410
Subject: Using BUS'es in ISE WebPACK 3.3WP8.1 ???
From: Per Jensen <per@fjernmigzapro.dk>
Date: Sat, 22 Jul 2006 01:08:59 +0200
Links: << >>  << T >>  << A >>
Hi!

I have a lot of PCB's with the XCR5064C CPLD on them, and would like to 
put them to use.

I am forced to use old software, since the new WebPACK doesn't have 
support for the old devices.

I have used several hours browsing the help file to find out how i 
connect anything on a BUS (e.g. CB16CE output pins (15:0)

I am going absolutely crazy, i can't find out how i do it!

Can anyone tell me how i do this, step for step, as i am a new user of 
CPLD's. - preferrably link to a online article describing how it's done.

As a start i would like to try this program:
http://coen.boisestate.edu/smloo/rapidprototyping2005/manual/UM-SCH-Spartan3.pdf
- yes i know i don't have a Spartan3, and the software version is not 
the same, but the idea behind is what counts. I like to start with the 
small things.

Regards,
Per Jensen,
Denmark.

Article: 105411
Subject: fpgadbg - a free & open source tool for FPGA debugging
From: Wojciech Zabolotny <wzab@ipebio15.ise.pw.edu.pl>
Date: Fri, 21 Jul 2006 23:30:49 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi All, 

I have put a first, quick&dirty version of my "fpgadbg" tool
on the website: http://www.ise.pw.edu.pl/~wzab/fpgadbg

This tool allows to record the signals inside of FPGA, and
then read the recorded data e.g. via the VME or other interface.

The recorded data may be then converted into the LXT file,
which may be browsed and analysed with the gtkwave viewer.
-- 
Regards, 
Wojtek Zabolotny
wzab@ise.pw.edu.pl

Article: 105412
Subject: Re: Last Chance for Tarfessock1 Features
From: "John Adair" <g1@enterpoint.co.uk>
Date: 22 Jul 2006 00:38:17 -0700
Links: << >>  << T >>  << A >>
It is a bit ironic but we actually probably ship more development
boards to the US than within the UK. There is also a strange US tax
situation such that our products are taxed lower than a US local
company. A import tax called MFP does apply but is very small but I
don't think Federal or State taxes get levied. If I'm wrong on that do
tell me. We have spend many many hours talking and emailing various US
bodies to try and get a definative answer without success.

Here in the UK our equivalent-ish VAT gets applyed to everything
including our daily Digikey orders.

It is also worth saying that if you take the FEDEX option for carriage
that in most cases you will get an order within 2 days. Occasionally
customs will upset that schedule but this is a fairly low percentage
and beyond our control to do anything about. The low cost carriage
option we believe takes usually less than a week to get there if you go
for that option.

When we release the product I don't expect everything will be as
polished as desireable but we will try and get a level that is
generally OK. The basic level that I will expect to launch with will be
Device1(XC3S250E) looking a Parallel Port/Parallel Cable III supporting
the bigger Device2(XC3S1200E). If we get the build right it should just
be a Parallel Port to the OS and will pick up a driver automatically.
Beyond that basic level we will be producing a software GUI etc. to
access A/D, DAC etc but that needs some time to sort put and unlikely
to available at launch.

John Adair
Enterpoint Ltd.

John_H wrote:
> I've had passing interest in your offerings before - they look reasonable
> for the price and functionality offered.  Your discussion about acute
> attention to differential I/O and use of BGA packages is making me think
> more seriously about shipping stuff across the pond.  For Tarfessock1, I'm
> left wondering what needs to be developed by me versus what you would supply
> for CardBus access.  I'm the FPGA guy, not into Windows drivers to save my
> life.
>
> I'll take another, closer look at your site this weekend, particularly the
> info you've generated so far for Tarfessock1.
>
> - John_H
>
>
> "John Adair" <g1@enterpoint.co.uk> wrote in message
> news:1153510536.728994.136460@75g2000cwc.googlegroups.com...
> > All of our development boards support LVDS with matched pair routing.
> > Even our low cost Raggedstone has about 50+ pairs of signals usually
> > matched in length 1mm or less that run together from the relevant pair
> > on the FPGA to the DIL headers. They don't share with other things
> > generally either. This is part of the reason we use large I/O count
> > devices even on our cheap boards. It is a major differentiation between
> > our product and something like the Spartan-3 and 3E starter kits that
> > use relatively small I/O count devices. We also tend use the large size
> > package because of the SSO advantage and in fact we have an internal
> > production test for some the boards with a very large percentage of
> > I/O, at large toggle rate, running over our boards at 50Mhz and we get
> > very good performance. Conversely we have seen other peoples designs
> > that use PQFP and TQFP packages having very serious issues with small
> > percentage toggle rates at relative low frequencies and the advantage
> > of a BGA package is very large and well worth the little bit of extra
> > money to have in most design cases.
> >
> > Tarfessock1 will have support for LVDS built in a good percentage of
> > the I/O if not all, I expect we will have 20+ pairs maybe even the lot
> > to give 35 pairs. The grounding we will have to see how good it is and
> > whether virtual grounds from FPGA I/Os are needed. However we do want
> > to maintain the planned 70 I/O as it is fairly key to what we want to
> > do outside the card itself. Ultimately whatever we do we won't please
> > everyone and that is what market choice for. I do think we have formula
> > that will win a lot of friends especially when the planned extended
> > functionality becomes clearer in the shape of future add-on modules. I
> > don't think the price is bad either especially if you qualify for
> > student pricing but I'm sure someone will still point out the card
> > costs more than it's constituent parts and designing it is cheap and
> > not be equated in the price.
> >
> > John Adair
> > Enterpoint Ltd.


Article: 105413
Subject: Re: Last Chance for Tarfessock1 Features
From: "John Adair" <g1@enterpoint.co.uk>
Date: 22 Jul 2006 00:57:08 -0700
Links: << >>  << T >>  << A >>
I will see what we can do. The physical size of a Cardbus card does not
allow much room for an optimal placement to trace length match. We may
also have problems finding enough board area too and I don't think
double siding components is a serious option given the tight height
restrictions.

At the 33Mhz the Cardbus notionally works at you would not have any
issues using a common source clock of this frequency on any interface
between the devices. Device1 is strictly limited in size and generally
the intention is that most customers will not touch the shipping build
programmed in. The through-put from Device2, via Device1 + Cardbus, to
outside world will be limited by the Cardbus itself negating the need
for a super fast interface between the devices. That all said we trying
to support LVDS on the interface between the devices and a source
synchronous approach will definately yield high bandwidth. I will be
able to tell you more in a couple of weeks when the design will be
pretty much fixed in schematic and layout placement.

John Adair
Enterpoint Ltd.

Nico Coesel wrote:
> "John Adair" <g1@enterpoint.co.uk> wrote:
>
> >Web page with block diagram and outline spec is now on website here
> >http://www.enterpoint.co.uk/moelbryn/tarfessock1.html.
>
> How about a programmable clock source? Even better, one which has
> equal / matched lines to each FPGA so both FPGAs get the same clock.
> Multiple independant frequencies would be better. This may also be a
> good selling point for universities, crossing a clock boundary is not
> trivial in most cases.
>
> --
> Reply to nico@nctdevpuntnl (punt=.)
> Bedrijven en winkels vindt U op www.adresboekje.nl


Article: 105414
Subject: Re: MIG DDR2 controller does not work (reset problems?)
From: heinerlitz@gmx.de
Date: 22 Jul 2006 01:45:42 -0700
Links: << >>  << T >>  << A >>
Hi Joseph,

thanks a lot I will check all the thing you suggested and yes its a
board made by us.

Still I have some questions:

The Calibration process with the dummy reads can be definitely observed
using chip scope and it seems to be ok as the tap_select signal is
asserted. Does that mean that at least the control and the DQS signals
should be fine. The question I have is the following in the init
sequence the controller just writes data to the RAM, the Ram itself
does practically nothing. SO assuming the RAM wouldnt consist at all
would the init and calibration sequence still be succesfull?


I tried a board without RAM assembly and it didnt do anything so I
assume not..
As I said before the data compare module fails so it could be a signal
inttegrity problem which casuses the read out data to be corrupt.

heiner


Joseph Samson schrieb:

> heinerlitz@gmx.de wrote:
> > Hi ive got some news,
> >
> > the init and calibration process seems to be succesful as tap_sel_done,
> > data_tap_select and init_memory signals toggle at the end of the
> > calibration process.
> >
> > However the init_done signal which is driven by COMP_DONE is not
> > asserted. As COMP_DONE is generated by the pattern compare module, it
> > seems to me that the read out data is corrupted.
> >
> > Could this be right?
> > Am I right with my conclusions?
> > What to do now?
>
> I'm assuming that this is a board of your own design, and not a
> prototyping board you bought off the shelf, because my first guess would
> be that there is either a mis-wiring problem (my board had the
> differential clock signals miswired + to -, even though we checked the
> schematic about a hundred times) or a signal integrity problem (like
> those missing terminators). You can try turning on ODT. You can either
> change the parameters_0.v file, or regenerate the design from CoreGen,
> clicking on the 'Set Mode Register" button and setting RTT to 75 ohms.
>
> There are two lines of attack:
> 1. Is the command and address correct?
> 2. Is the data correct?
>
> There are indirect ways to see if the commands are correct. Earlier, I
> said that part of the calibration is to issue read commands and
> calibrate the idelay by examining the datastrobes. If you are getting
> through that phase and you see datastrobes being generated, then the
> commands (RAS, CAS, WE, CKE, CS) are probably OK, or at least I'd look
> elsewhere.
>
> It's hard to tell if the address bus is OK without using a scope on the RAM.
>
> You can use ChipScope to see what the data looks like coming from the
> RAM, but be sure that you aren't accidentally connecting to signals that
> go to the IOB. The address and command signals go go IOB flipflops, but
> chipscope will happily move them out of the IOB so you can look at them,
> and as a bonus, you'll get lots or routing delay to confues the issues.
>
> If this is your own design, did you pay attention to the routing delays?
> My first design spec'd that signals had to be length matched to 200ps.
> In my second design, I spec'd 20ps. You could have everything correct,
> but the difference in path length could prevent the calibration circuit
> from aligning all the bits.
> 
> 
> ---
> Joe Samson
> Pixel Velocity


Article: 105415
Subject: Re: Virtex 4, LVDS I/O: Sanity check please
From: "John Adair" <g1@enterpoint.co.uk>
Date: 22 Jul 2006 02:08:25 -0700
Links: << >>  << T >>  << A >>
Your biggest issue is not the top surface area for the resistor site
but the via space and extra routing needed to connect resistors. The
vias especially will have significant routing effects. Even using a
microvia blocks the path for potentially an extra signal. Conventional
vias block 2 traces worth in our standard technology. BGA resistor
packs whilst small tend not to have a good run of routing them and
generally increase layer count to achieve the end result.

John Adair
Enterpoint Ltd.

PeteS wrote:
> John Adair wrote:
> > Standards like SSTL are good for this due to the low signal swing. The
> > biggest decision is if to use DCI which burns more power in the V4 or to use
> > external resistors which take board area and make routing more difficult.
> >
> > The other decision is weither you use source synchronous clocking or a
> > common clock approach. At 150 Mhz the common clock is slightly marginal
> > depending on how long tracks are, speed grade, etc. unless you use some DCM
> > based techniques. You can generate a clock that is offset from the common
> > clock a little by using a DCM and use that as clock for register input to
> > gain more time. Alternatively you can use a DCM to null out the clock to
> > output time and get more margin from that.
> >
> > John Adair
> > Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development
> > Board.
> > http://www.enterpoint.co.uk
> >
> >
> > "Marc Reinig" <Marco@newsgroups.nospam> wrote in message
> > news:44bc1fed@darkstar...
> > >I have a project where I will have a large array of V4 FPGAs.  Each chip is
> > >intended to connect to its four orthogonal neighbors with no intervening
> > >logic.  I would like the number of bus connections between chips in any
> > >direction in the array to be 150 (600 total I/O per chip).  The connections
> > >will be bi-directional.  The distance between chips will be the minimum I
> > >can have with sockets, heat sinks (with individual fans), good layout and
> > >noise control.  Some of the lines, what ever is necessary, will be used for
> > >clock and framing for the bus data signals.  I would like to use DDR.
> > >During bus transfers, all the lines on opposite sides of the chip will be
> > >operating and the other two sides will be quiescent.  I'm hoping for a bus
> > >clock of 150 MHz.
> > >
> > >
> > > Comments? ;=)
> > >
> > > Marco
> > > ________________________
> > > Marc Reinig
> > > UCO/Lick Observatory
> > > Laboratory for Adaptive Optics
> > >
> > >
>
> If Marc uses SSTL, and uses resistive terminators, I would agree it
> takes board space, but I disagree it would make routing significantly
> more difficult, except for the sheer number of devices. In a point to
> point situation only a series terminator is really required for speeds
> up to at least 200MHz / 400Mb/s (I've done it).
>
> Assuming these busses would be bidirectional, external series resistors
> would [arguably, at least] actually be better in reducing EMI and
> reflections than just DCI (less power too) assuming the devices are
> close together (of the order of perhaps 4 inches or less). Much really
> depends on the distance. I've used BGA style resistor packs that cram
> more resistors into the device than can be done in multipack type SMT
> devices. Apart from that, the tiny quad pack devices are particularly
> sensitive to even slightly imperfect chip shooters and have a nasty
> tendency to crack the resistor, particularly at the ends of the device.
>
> CTS corp makes a particularly nice range of devices
> (http://www.ctscorp.com/components/clearone.asp) [I have no affiliation
> with them except for having used the parts in the past].
> 
> Cheers
> 
> PeteS


Article: 105416
Subject: Re: Last Chance for Tarfessock1 Features
From: "John Adair" <g1@enterpoint.co.uk>
Date: 22 Jul 2006 02:15:07 -0700
Links: << >>  << T >>  << A >>
Any idea of a rough price on 5V9885? It looks useful although the
jitter spec would not be good enough for high end applications. ICS8442
does a lot better in that respect.


John_H wrote:
> I found the IDT5V9885 to be surprisingly cost effective.  Intended to be a
> clock generator rather than a zero delay buffer style of clock regenerator,
> the filtering selections for on-chip filters appear to make the device
> robust enough for serious clock cleanup.  Even spread spectrum is available
> within the one integrated device.  I don't know if I'll get it on the
> prototypes due back within the month (I'm only a contributor, not the
> designer) but I sure would love to work with that part!  External part count
> is low, programmability is high.
>
> "Nico Coesel" <nico@puntnl.niks> wrote in message
> news:44c140f7.1387066536@news.kpnplanet.nl...
> > "John Adair" <g1@enterpoint.co.uk> wrote:
> >
> >>Web page with block diagram and outline spec is now on website here
> >>http://www.enterpoint.co.uk/moelbryn/tarfessock1.html.
> >
> > How about a programmable clock source? Even better, one which has
> > equal / matched lines to each FPGA so both FPGAs get the same clock.
> > Multiple independant frequencies would be better. This may also be a
> > good selling point for universities, crossing a clock boundary is not
> > trivial in most cases.
> >
> > --
> > Reply to nico@nctdevpuntnl (punt=.)
> > Bedrijven en winkels vindt U op www.adresboekje.nl


Article: 105417
Subject: Re: Spartan III development: which tools, what kind of PC?
From: "Kishore" <kishore2k4@gmail.com>
Date: 22 Jul 2006 03:50:44 -0700
Links: << >>  << T >>  << A >>
Hi,

    Indeed, the latest version of ISE is very slow. Here is a list of
things that I did to improve them.

->More RAM, If you are working on reasonably large projects 2GB of RAM
would show considerable improvement
->RAID-0 for your installation directories and pagefiles and RAID-1 for
project files.
->If you happened to have any antivirus programs running, by all means
do disable them.
->Last but not least, you may want to try incremental synthesis on
large projects.


   Ok, this may sound expensive but you may want to consider Intel Core
2(conroe) that will be available early august. Its nearly 200% faster
than your current configuration.

cheers,
kishore.


Deefoo wrote:
> A couple of years ago we've done some Spartan II development with Xilinx ISE
> tools (V5.2.03i). Now we want to do a design with a Spartan III but our
> tools are out of date or have expired. We've tried the Webpack 8.1i on a
> 3GHz Prescott with 1GB of RAM and found it very slow. Hence my question:
>
> What is a good system setup for reasonable comfortable Spartan III
> development? What kind of PC do we need and which tools?
>
> We don't want to spend too much on tools since we do FPGA only occasionally,
> but if our engineer is spending most of his time waiting for his tools to
> finish a job we may be better of spending a bit more.
> 
> Thanks,
> --DF


Article: 105418
Subject: Re: corrupted data when accessing dual port bram in Cyclone II
From: "homoalteraiensis" <fpgaengineerfrankfurt@arcor.de>
Date: 22 Jul 2006 04:47:56 -0700
Links: << >>  << T >>  << A >>
Thanks to all so far. As mentined , I am busy with other parts of the
design to go deeper into that at the moment. TimeQuestAnalyzer will be
the next step.


Article: 105419
Subject: Re: Using BUS'es in ISE WebPACK 3.3WP8.1 ???
From: Per Jensen <per@fjernmigzapro.dk>
Date: Sat, 22 Jul 2006 15:31:24 +0200
Links: << >>  << T >>  << A >>
Per Jensen skrev:
> Hi!
> 
<CUT>
> 
> Can anyone tell me how i do this, step for step, as i am a new user of 
> CPLD's. - preferrably link to a online article describing how it's done.
> 

BUMP!

Anybody ??? I can't be the only one with this problem....

Regards, Per.

Article: 105420
Subject: Re: Virtex 4, LVDS I/O: Sanity check please
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 22 Jul 2006 07:22:49 -0700
Links: << >>  << T >>  << A >>
John Adair wrote:
> Your biggest issue is not the top surface area for the resistor site
> but the via space and extra routing needed to connect resistors. The
> vias especially will have significant routing effects. Even using a
> microvia blocks the path for potentially an extra signal. Conventional
> vias block 2 traces worth in our standard technology. BGA resistor
> packs whilst small tend not to have a good run of routing them and
> generally increase layer count to achieve the end result.
>
> John Adair
> Enterpoint Ltd.

Depends on what is being routed, of course.

In this particular application, the signal can go in and out very
easily (1 track between balls for each ball position) and no vias at
all are required.

In a parallel termination case, things are different, but for a series
terminator, the devices I have used work just fine with no extra layer
count required. Indeed, the part manufacturers are aware of the issue
that saving space for the package but providing poor access negates any
advantage of the package size, so parts are appearing that have decent
routing ability.

Cheers

PeteS


>
> PeteS wrote:
> > John Adair wrote:
> > > Standards like SSTL are good for this due to the low signal swing. The
> > > biggest decision is if to use DCI which burns more power in the V4 or to use
> > > external resistors which take board area and make routing more difficult.
> > >
> > > The other decision is weither you use source synchronous clocking or a
> > > common clock approach. At 150 Mhz the common clock is slightly marginal
> > > depending on how long tracks are, speed grade, etc. unless you use some DCM
> > > based techniques. You can generate a clock that is offset from the common
> > > clock a little by using a DCM and use that as clock for register input to
> > > gain more time. Alternatively you can use a DCM to null out the clock to
> > > output time and get more margin from that.
> > >
> > > John Adair
> > > Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development
> > > Board.
> > > http://www.enterpoint.co.uk
> > >
> > >
> > > "Marc Reinig" <Marco@newsgroups.nospam> wrote in message
> > > news:44bc1fed@darkstar...
> > > >I have a project where I will have a large array of V4 FPGAs.  Each chip is
> > > >intended to connect to its four orthogonal neighbors with no intervening
> > > >logic.  I would like the number of bus connections between chips in any
> > > >direction in the array to be 150 (600 total I/O per chip).  The connections
> > > >will be bi-directional.  The distance between chips will be the minimum I
> > > >can have with sockets, heat sinks (with individual fans), good layout and
> > > >noise control.  Some of the lines, what ever is necessary, will be used for
> > > >clock and framing for the bus data signals.  I would like to use DDR.
> > > >During bus transfers, all the lines on opposite sides of the chip will be
> > > >operating and the other two sides will be quiescent.  I'm hoping for a bus
> > > >clock of 150 MHz.
> > > >
> > > >
> > > > Comments? ;=)
> > > >
> > > > Marco
> > > > ________________________
> > > > Marc Reinig
> > > > UCO/Lick Observatory
> > > > Laboratory for Adaptive Optics
> > > >
> > > >
> >
> > If Marc uses SSTL, and uses resistive terminators, I would agree it
> > takes board space, but I disagree it would make routing significantly
> > more difficult, except for the sheer number of devices. In a point to
> > point situation only a series terminator is really required for speeds
> > up to at least 200MHz / 400Mb/s (I've done it).
> >
> > Assuming these busses would be bidirectional, external series resistors
> > would [arguably, at least] actually be better in reducing EMI and
> > reflections than just DCI (less power too) assuming the devices are
> > close together (of the order of perhaps 4 inches or less). Much really
> > depends on the distance. I've used BGA style resistor packs that cram
> > more resistors into the device than can be done in multipack type SMT
> > devices. Apart from that, the tiny quad pack devices are particularly
> > sensitive to even slightly imperfect chip shooters and have a nasty
> > tendency to crack the resistor, particularly at the ends of the device.
> >
> > CTS corp makes a particularly nice range of devices
> > (http://www.ctscorp.com/components/clearone.asp) [I have no affiliation
> > with them except for having used the parts in the past].
> > 
> > Cheers
> > 
> > PeteS


Article: 105421
Subject: Re: Using BUS'es in ISE WebPACK 3.3WP8.1 ???
From: "radarman" <jshamlet@gmail.com>
Date: 22 Jul 2006 07:54:25 -0700
Links: << >>  << T >>  << A >>

Per Jensen wrote:
> Per Jensen skrev:
> > Hi!
> >
> <CUT>
> >
> > Can anyone tell me how i do this, step for step, as i am a new user of
> > CPLD's. - preferrably link to a online article describing how it's done.
> >
>
> BUMP!
>
> Anybody ??? I can't be the only one with this problem....
>
> Regards, Per.

It appears you have hit the limit on Xilinx tolerance for older parts.
I was able to find a datasheet for the device, though.

http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/partinfo/xcr5064c.pdf

The datasheet is dated Feb. 10, 2000 - which means you probably need
ISE 4.x. You might try the classic webpacks, and see if they have
something that goes back that far.

I have a copy of 4.2i at work, so I can check back Monday with whether
it supports this device or not. I suspect it will, as the datasheet
specifically mentions that you can use VHDL/Verilog in addition to ABEL
and schematic capture.

Regards,
-Seth


Article: 105422
Subject: Re: HW Debug tools
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 22 Jul 2006 14:57:33 GMT
Links: << >>  << T >>  << A >>
"John Adair" <g1@enterpoint.co.uk> wrote:

>One thing worth considering is using logic analyser cores from Xilinx -
>Chipscope or Altera - Signaltap themselves alone. If you are on a
>tightish budget they are very cost effective and very good. We find we
>don't usually need anything more and they are very portable, i.e.
>laptop, if you need to work in the field. Downside of thsee tools is
>they need resource in the FPGA.  Using one of the hookups to an
>external analyser does mean less resource used in the FPGA and that is
>generally the only time I would use such an analyser. Even then I would
>take the option, if available, of starting with an oversized FPGA to
>allow the build in of an analyser function rather than plan to use an
>external analyser.

Still, an external analyser has a much deeper storage than available
inside an fpga. And a logic analyzer doesn't need to be expensive. For
instance, my ancient DAS9200 with 92C96XD card has up to 512k points
per channel (at 400Ms/s). I bought it on Ebay a few years ago for 66
US Dollar. Every now and then a TLA500 or TLA510 (the little brothers
of the DAS9200) unit pops up.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 105423
Subject: How to print a state flow graph for a state machine using Xilinx ISE or ModelSim
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 22 Jul 2006 09:09:35 -0700
Links: << >>  << T >>  << A >>
Hi,
Can you help explain a method to print a state flow graph for any state
machine design written in VHDL using either Xilinx ISE or ModelSim
software?

If neither has the ability of doing the function, what else software
can do it?

Thank you.

Weng


Article: 105424
Subject: Re: How to print a state flow graph for a state machine using Xilinx
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 22 Jul 2006 09:28:02 -0700
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote:

> Can you help explain a method to print a state flow graph for any state
> machine design written in VHDL 

Altera Quartus has such a viewer.

    -- Mike Treseler



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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