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
2019JanFebMar2019

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 63250

Article: 63250
Subject: Re: Xilinx UART Macro ERROR???
From: john@jrobot.net (john orlando)
Date: 18 Nov 2003 13:34:42 -0800
Links: << >>  << T >>  << A >>
Thank you for your response Ken.

We have used the macro before with little difficulty.

We were aware of the metastability problem with the serial input. 
We have the synchronization flip-flops in our design.

We found the problem. It was not with the UART macro. It was with our
use of the macro.

We were using the rising edge of OE- to generate our read pulse. By
the time OE- was synchronized and the edge detected we were 1 to 2
cycles past the rising edge of OE-. We were assured that the data
would not be changing when the processor read the data. This also
allowed us to read the data with zero wait states.

The problem we ran into was when the buffer was empty. If the received
byte was completed between when the processor read the data and the
read pulse then the macro would clear Data_Present and the byte would
be over written on the next received byte.

This was exaggerated by the fact that we were using bit 8 (we have a
32 bit bus) of a data read to provide the Data_Present status. With
one read we can get a received byte and status at the same time
instead of one read for data and another read for status. This caused
us to always do one more read than the data we had. If the input
buffer was truly empty this did not cause a problem.

The way we are fixing it is to latch the Data_Present status with our
Register_Enable signal and then use this latch version to gate the
read pulse. So if we read the buffer and Data_Present is not asserted
on the rising edge of Register_Enable the read pulse will not be
generated.

The problem with this is to detect the rising edge of Register_Enable
and latch Data_Present causes us to have to add 2 additional wait
states for our FPGA accesses.

Thanks to everyone who took the time to respond.

John

Ken Chapman <chapman@xilinx.com> wrote in message news:<3FB8A405.57F8D5BB@xilinx.com>...
> So I confess it was me that made the macros in XAPP223 and I made a
> mistake or at least an assumption.
> 
> The serial input to the Rx is of course asynchronous to the clock and
> therefore should be synchronised to the internal clock domain before it is
> distributed. My macro did not do this. Unfortunately, I always use the
> input flip-flops in the I/O blocks whenever possible in all designs and as
> such all my testing never showed up an error. Occasional reports of errors
> have always been cleared up by using a flip-flop in the serial line and of
> course putting it in the IOB makes it free. Other than this issue, I have
> had only happy reports by the thousand (plus requests for parity support
> of course!).
> 
> I have learnt from my mistake and have now re-implemented the UART macros
> which are currently bundled with PicoBlaze (www.xilinx.com/picoblaze)
> since this is where they get the most use and where the micro controller
> is an ideal partner. These macros have included input synchronising
> flip-flops so that they don't rely on I/O flip-flops. I guess I had to
> give up an additional slice of logic to make things easier to use :-)
> 
> Ken Chapman

Article: 63251
Subject: CFP: EH-2004 Second Call for Abstracts
From: eh-2004@ehw.jpl.nasa.gov (EH-2004)
Date: 18 Nov 2003 13:45:58 -0800
Links: << >>  << T >>  << A >>
Dear Colleague,

The abstract submission deadline (December 1st, 2003) for the 2004
NASA/DoD Conference on Evolvable Hardware is now approaching. The
main purpose of the one-page abstract is to provide the authors
early feedback before submitting the full paper. This will also
allow the Conference organization to start preparing the sessions
in advance.

Due to the one-page limit of the abstract, we would encourage the
authors to outline the forthcoming paper contents, explain the
main objectives of their research and summarize  expected results
if that is the case.

The conference web site is at:
  http://ehw.jpl.nasa.gov/events/nasaeh04/index.html
Please do not hesitate to contact the Conference Chair, Ricardo
S. Zebulum, (ricardo@brain.jpl.nasa.gov) if you have any
questions.

Abstracts should be submitted electronically to
eh-2004@cism.jpl.nasa.gov.

Hope to see you in Seattle!!!!

Ricardo Zebulum
David Gwaltney
Gregory Hornby
Didier Keymeulen
Jason Lohn
Adrian Stoica

---------------------------------------------------

2004 NASA/DoD Conference on Evolvable Hardware

  June 24- 26, 2004
  Seattle, Washington, USA
  Hotel (TBD), Seattle, WA

 Sponsored by:
  National Aeronautics and Space Administration (NASA)
  Department of Defense (DoD)

 Supported by:
  Life Detection Science and Technology, JPL (LDST, JPL)
  Space Exploration Technology Program, JPL (SETP, JPL)
  Information Sciences and Technology Directorate,
     NASA Ames Research Center(NASA Ames)
  Computing, Information and Communications Technology Program,
     NASA Ames Research Center(CICT)
  Advanced Computing Applications Office, NASA Marshall Space
     Flight Center (MSFC)
  Navy Center for Applied Research in Artificial Intelligence,
     Naval Research Laboratory (NRL)

 Hosted by:
  Jet Propulsion Laboratory (JPL, EHW group at JPL)

The 2004 NASA/DoD Conference on Evolvable Hardware (EH-2004)
builds upon the tradition of the successful series of NASA/DoD
Workshops (the first Workshop hosted by JPL in Pasadena, 1999; the
second Workshop hosted by NASA Ames in Palo Alto, 2000; and the
third Workshop hosted by JPL in Long Beach in 2001) and
Conferences (2002 hosted by NASA Goddard in Washington, DC and
2003 hosted by AMES in Chicago ) on Evolvable Hardware. Evolvable
Hardware is an emerging field that applies evolution to automate
design and adaptation of physical reconfigurable and morphable
structures such as electronic systems, antennas, MEMS and robots.
The purpose of this conference is to bring together leading
researchers from the evolvable hardware community, representatives
of the automated design and programmable/reconfigurable hardware
communities, technology developers and end-users from the
aerospace, military and commercial sectors.

Evolvable hardware techniques enable self-reconfigurability,
adaptability and learning by programmable devices and thus have
the potential to significantly increase the functionality of
deployable hardware systems. Evolvable Hardware is expected to
have major impact on deployable systems for space systems and
defense applications that need to survive and perform at optimal
functionality during long duration in unknown, harsh and/or
changing environments. It is also expected to greatly enhance
the capability of systems that need modification, upgrade and
learning without interrupting their operation.

This year's Conference will introduce two new features: early
submission of abstracts previous to full-paper submission and the
organization of Special Sessions.


SUBMISSION OF ABSTRACTS

Prospective authors are invited to submit the electronic version
of their abstract (ie PS, PDF, MSWord) by email to
eh-2004@cism.jpl.nasa.gov . The abstract is limited to 1 page and
should be submitted in single-spaced, 10 point type on a 8.5"x11"
or equivalent paper with 1" margins on all sides.  Each submission
should contain the following items: (1) title of paper, (2) author
name(s), (3) first author physical address, (4) first author e-mail
address, (5) first author phone number, (6) the text of the
abstract, and (7) references.

IMPORTANT DATES

Abstract submission deadline:          December 1, 2003
Author notification abstract:          December 15, 2003
Paper submission deadline:             January 31, 2004
Author notification paper:             March 15, 2004
Camera ready manuscript deadline:      March 31, 2004
Conference:                            June 24-26, 2004

Article: 63252
Subject: Re: Do I need to connect all Vref in a bank together?
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Tue, 18 Nov 2003 22:17:53 GMT
Links: << >>  << T >>  << A >>
On a sunny day (Tue, 18 Nov 2003 12:35:19 +1300) it happened Jim Granville
<jim.granville@designtools.co.nz> wrote in <3FB95B37.5E2@designtools.co.nz>:

> You could also try a Tracking ADC, rather than SAR - SAR is sensitive
>to
>noise, and have 'noise gain' which means large OP impulse errors can
>come from small IP errors. (which is what you are seeing) 
> Tracking ADCs are better behaved, and would suit the faster speed / 
>but not analog-optimised resource in the FPGA.
>
> - jg
Interesting, how (in priciple0 would you realize a 'tracking ADC'?
This is what I do now (sort of pseudo code):

// signal output from comparator is in inbit

reg [3:0] position; // bit position
reg [7:0] temp; // temp 
always  ....
begin
if(position > 0)
 begin
 temp[position] = 1 - comparator;

 if(comparator == 0)
  da_output[7:0] = da_output[7:0] + substractor[7:0];
 else
  da_output[7:0] = da_output[7:0] - substractor[7:0];

 position = position - 1;

 substractor = substractor >> 1;
 ready = 1'b0;
 end
else // bit 0
 begin
 ready = 1'b1;
 substractor = 8'd64;
 da_output = 8'd128;
 position = 8'd7;
 output = temp;
end

end // always

I left out the trigger (conversion request) and reset.
I start with the r2r DA at 128 (half of 255 8 bit range),
and the substractor at 64 (half of remaining range.
One clock later I check the comparator output, and store
the bit.
If the value was bigger I go to 128 + 64 and compare again..
if smaller to 128 - 64...


decrement the bit, and have teh substractor value.
When bit zero comes, I copy the temp result and set ready.

The real routine is bigger and does things on pos and neg edge clock.

How would you write a 'tracking' one?
It should not use more steps.... if possible?
Jan

Article: 63253
Subject: Re: Altera's altsyncram MAXIMUM_DEPTH
From: petersommerfeld@hotmail.com (Peter Sommerfeld)
Date: 18 Nov 2003 14:30:30 -0800
Links: << >>  << T >>  << A >>
Hi Manfred, Subroto:

Thank you very much for your in-depth replies. I'm happy to see that
MAXIMUM_DEPTH does what I was hoping it does, because I need many RAMs
at non-power-of-2 bits storage, and I'm feeling a little too lazy to
write my own muxing logic.

Manfred, I compiled a design that had one depth-first and one
width-first RAM block, each being 1,089 x 32 bits. The depth-first
used 16 M4k's as 4096x2, and the width-first used 9 M4k's as 128x32,
so the functionality appears to be working for me. Perhaps certain
memory configuration work properly with MAXIMUM_DEPTH, while others
(ie. yours) do not?

As expected the critical path was in the width-first logic, but was
still 220 MHz+.

I am using Quartus II 3.0 SP2. I found the release notes at
http://www.altera.com/literature/rn/rn_qts.pdf.

Thanks again,

-- Pete

Manfred Mücke <manfred.getmuecke@ridgmxof.thisat> wrote in message news:<oprysn2vdygdoir8@news.inode.at>...
> Hi Peter,
> 
> > I am wondering if I am missing out on a possible memory optimization.
> yes you do.
> 
> Quartus allocates memory by depth first, 512x8bit therefore uses two M4Ks 
> in 512x4 mode. If your memory width and depth is a power of two, allocation 
> order doesn't matter except for some speed details. But a 700x8bit memory 
> is much better allocated by width than by depth (because only 3 M4Ks are 
> needed for the first compared to 4 for the latter). (see 
> http://www.altera.com/support/kdb/rd03292002_9305.html for further details)
> MAXIMUM_DEPTH should help you to force Quartus not to waste this addtional 
> memory block.
> 
> Unfortunately it doesn't work. Not even the way Altera thinks it should 
> work. I had a long (and somewhat bizarre) service request the last entry 
> being the following one:
> 
> -- Altera wrote
> This is to let you know that a software problem request has been filed in 
> order to reflect this issue.  I will let you know as soon the software 
> group gets back to me with any infomation or when a resolution is made.
> -- Altera wrote much more, but [snip]
> 
> This was written the 25th of august and the service request was closed 
> without further comment. I have posted an additional request asking for the 
> actual state of the problem request about one month ago and did not receive 
> any answer. Either Altera doesn't care or they don't want to state that 
> this is an issue at present before they are able to ship the new Quartus 
> 4.0 (hopefully fixing this and a lot of other things) - who knows?
> If anyone in the group thinks he can help on this topic or has further 
> details I would be thankful to hear about it as Quartus wastes a lot of my 
> memory and this has to change!
> 
> I have to say that life with Altera mySupport is very ambiguous to me. 
> Answers are generally quick and friendly (which is already a lot) but 
> generally only helpful when problems are simple. Whenever the problem gets 
> more complex or there is a bug thinks get very slow (or even stop).
> 
> Regards, Manfred
> 
> BTW: "Release notes for Service Pack 2 will be released on Friday, October 
> 24, 2003." (seen on 
> https://www.altera.com/support/software/download/service_packs/quartus/dnl- 
> qii30sp2.jsp the 17th november)
> 
> 
> 
> 
> ======= Service Request Detail (reordered for your convenience)
>  Request #: 10363308  Status: Closed  Date Opened (PDT): 8/19/03 9:03 AM  
> Date Closed (PDT): 9/4/03 6:52 PM  Inquiry Type: Product Question
> 
>  Device Family: CYCLONE  Device:
>    Title: FIFO implementation size
> 
>  Description: I have created a 1300word by 8bit FIFO (sfifo). The 
> implementation of this needs 16384 memory bits. Why?
> 
> The FIFO-size should result in about 1300x8=10400 memory bits. As the 
> blocksize of the embedded ram in Cyclone is 4096bits which can be organized 
> 512x8 I expect Quartus to use three M4K's resulting in 4096*3=12288bits. 
> Obviously it uses a fourth block, why?
> 
> Regards, Manfred
>  ------ 8/19/03 3:17 PM
>   To Customer
>   Hello Manfred,
> 
> This is to let you know that I am currently looking into this.  I will let 
> you know as soon as I am able to verify the problem as you have described 
> and come into a resolution.
> 
> ------ 8/19/03 4:20 PM
>   To Customer
>   Hello Manfred,
> 
> Since 1300 is larger than 1k, it'll use 2kx2 mode for best performance.  To 
> get the x8 mode you'll need 4 M4Ks.  Click custom on (page 6 out of 8 of 
> the megawizard), then you get an option to set Maximum depth option and if 
> you set 512 then it'll use that mode and should only need 3 M4Ks.
> 
> For more information on this, you may refer to the following link:
> 
> http://www.altera.com/support/kdb/rd03292002_9305.html
> 
> ------ 8/20/03 12:36 AM
>   From Customer
>   Hello Marlon,
> 
> thanks for your quick and helpful reply. Now the behaviour of Quartus is 
> clear to me.
> Unfortunately setting the parameter max. block depth to 512 in the 
> Megawizard Plug-In Manager as you proposed does not result in a smaller 
> memory consumption. I have attached the packed project for your 
> convenience.
> Setting this parameter adds the following line in the scfifo instantiation 
> code:           maximum_depth => 512,
> however this parameter is not described in the Quartus II help page for the 
> scfifo-Megafunction. Why?
> 
> Regards, Manfred
> 
> ------ 8/20/03 9:47 AM
>   To Customer
>   Hello Manfred,
> 
> The MAXIMUM_DEPTH parameter is an internal parameter so there won't be any 
> information on this in the Quartus II Help or Megawizard.
> 
> ------ 8/20/03 11:26 PM
>   From Customer
>   Hello Marlon,
> 
> again: Unfortunately setting the parameter max. block depth to 512 in the 
> Megawizard Plug-In Manager as you proposed does NOT result in a smaller 
> memory consumption. Why? Please check with the attached project file.
> 
> Regards, Manfred
>  ------ 8/21/03 5:08 PM
>   To Customer
>   Hello Manfred,
> 
> Sorry for the inconvenience, but actually, in order to get the x8 mode 
> you'll need 4 M4Ks.
> 
> ------ 8/21/03 11:49 PM
>   From Customer
>   Hello Marlon,
> 
> could you please specify why it is not possible to implement a 1300x8 FIFO 
> in 3 M4K Blocks as this information is the opposite of both your first 
> advice and the mentioned support database page 
> (http://www.altera.com/support/kdb/rd03292002_9305.html).
> What exactly is the parameter maximal block depth for then?
> 
> Regards, Manfred
> 
>  ------ 8/25/03 6:50 PM
>   To Customer
>   Hello Manfred,
> 
> This is to let you know that a software problem request has been filed in 
> order to reflect this issue.  I will let you know as soon the software 
> group gets back to me with any infomation or when a resolution is made.

Article: 63254
Subject: Re: xilinx platform flash question
From: "Barry Brown" <barry_brown@remove_this.agilent.com>
Date: Tue, 18 Nov 2003 15:22:25 -0800
Links: << >>  << T >>  << A >>
1. No problem.  I'm not a buyer, so I don't know where they came from.

3. Don't know, but if you hook up the CF pin to PROG, then you can tell
Impact to make the FPGA load from the PROM after the
programming/verification is complete.  You check a box in the "Program..."
dialog.

Barry

"Robert Sefton" <rsefton@abc.net> wrote in message
news:bpc3nl$1nibph$1@ID-212988.news.uni-berlin.de...
> I need to configure an XC2V6000 from flash. Planning to use six XCF04S
> PROMs, but I have a few questions.
>
> 1. Anyone having problems buying these PROMs? Avnet had some in stock
> last week, but today they had none. What kind of lead times should I
> expect?
> 2. Does the Xilinx Impact software fully support in-system JTAG
> programming of a chain of serial PROMs? Is ISE 5.2i sp3 the required
> version?
> 3. Does the software also support direct JTAG downloading to the FPGA if
> it sits at the end of the same JTAG chain with the PROMs in it?
>
> I'm a little wary of committing to this path and losing time due to tool
> problems or inability to get parts.
>
> Thanks,
>
> Robert
>
>
>



Article: 63255
Subject: Xilinx DCM LOCKED signal valid after input clock returns?
From: "Barry Brown" <barry_brown@remove_this.agilent.com>
Date: Tue, 18 Nov 2003 15:39:24 -0800
Links: << >>  << T >>  << A >>
OK, the DCM input clock goes away, and I understand the LOCKED signal is not
valid.  After the input clock comes back, can you rely on the LOCKED signal
to indicate that a DCM reset pulse is needed?

And ditto that question for the STATUS(2) signal when you are using the
CLKFX output?

I'm trying to avoid creating an extra independent clock (with some little
oscillator) that would be used to clock a state machine to generate the DCM
reset pulse when STATUS(1) indicates loss of input clock.  So I thought to
use the input clock itself for the state machine, and test the LOCKED signal
to decide about reset.  After all, there's no point in resetting the DCM
until after its input clock has returned.

I hoped the Xilinx website might have an example circuit to handle DCM
reset, but I couldn't find anything.

Barry Brown



Article: 63256
Subject: Re: Xilinx DCM LOCKED signal valid after input clock returns?
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Tue, 18 Nov 2003 16:02:06 -0800
Links: << >>  << T >>  << A >>
Barry,

Within a few thousands of clocks after the clock has returned (depending on the
settings of the jitter filters), the DLL will either be locked, or LOCK will go
low (indicating that the DLL has run off the ends of the delay lines due to the
interruption), or CLKIN_STOPPED will still be high indicating the clock really
did not come back as expected.

If the CLKFX output is also being used, and interruption at all will lead to the
CLKFX_STOPPED bit asserting high.

Easier to just use LOCKED going low after it has already gone high, OR
CLKIN_STOPPED going high OR CLKFX_STOPPED going high as your trigger to reset.

Hope this helps in your little state machine design.

Austin

Barry Brown wrote:

> OK, the DCM input clock goes away, and I understand the LOCKED signal is not
> valid.  After the input clock comes back, can you rely on the LOCKED signal
> to indicate that a DCM reset pulse is needed?
>
> And ditto that question for the STATUS(2) signal when you are using the
> CLKFX output?
>
> I'm trying to avoid creating an extra independent clock (with some little
> oscillator) that would be used to clock a state machine to generate the DCM
> reset pulse when STATUS(1) indicates loss of input clock.  So I thought to
> use the input clock itself for the state machine, and test the LOCKED signal
> to decide about reset.  After all, there's no point in resetting the DCM
> until after its input clock has returned.
>
> I hoped the Xilinx website might have an example circuit to handle DCM
> reset, but I couldn't find anything.
>
> Barry Brown


Article: 63257
Subject: Altera Stratix synthesis error
From: erojr <janos.nojunk.nospam.ero@cern.nojunk.nospam.ch>
Date: Tue, 18 Nov 2003 19:06:25 -0500
Links: << >>  << T >>  << A >>
I have transported a design from Altera APEX to STRATIX. The previous 
design´s Lookup Tables (LUTs) that were in ¨lpm_rom¨ modules have been 
transported to ¨altsynchram¨ modules. Now QuartusII3.0 sends an error 
message:

 > Error: Groups cannot be assigned to nodes

When I locate the message´s origin, it points to the following file:

/appl/quartusII3.0/libraries/megafunctions/altsyncram.tdf

Here on the line #1501:

     ram_block[0][i].portaaddr[] = address_a[];

The design itself was already simulated by Cadence(TM) on behavioral 
level, with all lpm-s inside, without any error. The Synthesis tool 
Synplify did not give error message either. Perhaps a bug in Quartus?

Any idea?

Thanks,

Janos Ero
CERN Div. EP


Article: 63258
Subject: XILINX Foundation F1.5 Build 3.1.1.35 with XCS10PC84 and Digilab XLA
From: komara5@comcast.net (Kevin O'Mara)
Date: 18 Nov 2003 16:11:26 -0800
Links: << >>  << T >>  << A >>
I am attempting to use this XILINX software with this board and chip. 
In order to test it, I create a simple design that incorporates an
AND2 gate, two input buffers, and one output buffer all of which (the
input and output buffers) are connected to IPADs.  The IPADs are
assigned pin numbers on the Schematic with the parameters LOC=Pxx,
where xx is 27, 28, and 69.  These correspond to SW1, SW2, and LD1.

The design implements correctly, and the bit file is generated
successfully.  When I transfer the design to the board, NOTHING
HAPPENS!

This is a very frustrating problem, and I cannot determine the
solution.  If I can't get this simple design to work, then the boards
are practically worthless.

I installed the two recommended updates for the F1.5 software,
ftp://ftp.xilinx.com/pub/swhelp/M1.5_updates/15_service_pack1_nt.zip
and ftp://ftp.xilinx.com/pub/swhelp/M1.5_updates/15_sp1_ftp2_nt.zip. 
I don't know what else I am supposed to upgrade the software with to
perhaps fix this problem.  I have already tried other miscellaneous
patches posted on the site, but none allows this simple design to
work.

Has anyone else encountered this problem with XILINX Foundation F1.5,
and the Digilab XLA with the XCS10PC84 chip?

Thank you.

--

Article: 63259
Subject: Re: Do I need to connect all Vref in a bank together?
From: "Jim Granville" <no.spam@designtools.co.nz>
Date: Wed, 19 Nov 2003 13:21:31 +1300
Links: << >>  << T >>  << A >>
"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
news:1069193901.982088@evisp-news-01.ops.asmr-01.energis-idc.net...
> On a sunny day (Tue, 18 Nov 2003 12:35:19 +1300) it happened Jim Granville
> <jim.granville@designtools.co.nz> wrote in
<3FB95B37.5E2@designtools.co.nz>:
>
> > You could also try a Tracking ADC, rather than SAR - SAR is sensitive
> >to
> >noise, and have 'noise gain' which means large OP impulse errors can
> >come from small IP errors. (which is what you are seeing)
> > Tracking ADCs are better behaved, and would suit the faster speed /
> >but not analog-optimised resource in the FPGA.
> >
> > - jg
> Interesting, how (in priciple0 would you realize a 'tracking ADC'?


> I left out the trigger (conversion request) and reset.
> I start with the r2r DA at 128 (half of 255 8 bit range),
> and the substractor at 64 (half of remaining range.
> One clock later I check the comparator output, and store
> the bit.
> If the value was bigger I go to 128 + 64 and compare again..
> if smaller to 128 - 64...

This is SAR, as you mentioned.

Tracking ADCs have a saturating Up/Dn counter, and INC/DEC based on the
comparitor result. They have a finite slew rate, but the counting
clock speed can be higher than the read-out rate.
Their advantage is the inherent low pass/noise filtering nature of the
feedback
so in a 'less than ideal' environment like a FPGA Comparitor/DAC, they could
help.

They can be made adaptive, so the INC/DEC size increases
if many INC/DECs occur in the same direction (as in ADPCM), to
improve the step response.
-jg



Article: 63260
Subject: Thank you all for the replays.
From: "Valentin Tihomirov" <valentin@abelectron.com>
Date: Wed, 19 Nov 2003 03:34:32 +0200
Links: << >>  << T >>  << A >>
I've got information that the CPLD uses 50k bus-holding feature. I've used
12k resistor in my reseting circuit instead of 130k and this solved the
problem. However, I turrend bus keeping off in WebPack->fitter option. It is
obusfucating. 3.3v*130/(130+50) = 2.35v I was getting when my 130k was
pulling reset down and CPLD's keeper feature pulled it up with 50k.
One thing I still do not understand is why 3.3v CPLD pulls up input to 2.4v.



Article: 63261
Subject: Anyone use HDL as design tool for PCBs?
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 18 Nov 2003 17:49:24 -0800
Links: << >>  << T >>  << A >>
Hi,
   Does anyone out there in usenet-land know of tools to let you design
Printed Circuit Boards with VHDL? I'm ready to switch from schematic entry,
I want portability! (And all the other good reasons I switched from
schematic entry for my FPGA designs) Anyone use a PCB layout tool that
accepts EDIF files? I see there are translator tools. Anyone ready to share
their experiences, pitfalls et cetera?
        thanks for reading, Syms.



Article: 63262
Subject: Re: Active-HDL 6.1 pricing
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Wed, 19 Nov 2003 13:04:49 +1100
Links: << >>  << T >>  << A >>
On 18 Nov 2003 07:53:10 -0800, petersommerfeld@hotmail.com (Peter
Sommerfeld) wrote:

>Oops, looking through the thread I see you want a Verilog sim.
>Symphony is only VHDL.

Symphony is a good example though.

A one-year node-locked license of the "Standard" version costs US$199.
There doesn't seem to be any comparable Verilog simulator in that
price range.

Regards,
Allan.

Article: 63263
Subject: Re: Active-HDL 6.1 pricing
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Wed, 19 Nov 2003 13:07:55 +1100
Links: << >>  << T >>  << A >>
On Tue, 18 Nov 2003 22:02:59 +0200, "Valentin Tihomirov"
<valentin@abelectron.com> wrote:

>Downlad a trial from Altec. This prevents you from ascking stupd questions.

Was that directed at me or Rick?  Which questions were "stupd" ?

Allan.

Article: 63264
Subject: Re: SPI 4.2 Core perceptions and Power
From: "Robert Sefton" <rsefton@abc.net>
Date: Tue, 18 Nov 2003 18:36:27 -0800
Links: << >>  << T >>  << A >>
Dan -

I assume you're talking about the Xilinx core from Modelware? I worked
on a project last year where we used the core in a Virtex2 on a
daughtercard to interface with and test the ASIC we built. I worked on
the ASIC SPI-4 interface and designed the boards, but I did not actually
do the SPI-4 FPGA work. I can't vouch for the power number, but it
sounds reasonable. It's very hard to isolate in a system beacause you
wrap a lot of logic around the core inside the FPGA. All in all the core
worked as advertised with the possible exception of dynamic alignment.
It's been out there for quite a while now. I personally wouldn't
hesitate to use it.

I forwarded your post to the engineer who did the FPGA work and his
edited response is below. The BGA connector he refers to is the
mezzanine connector between the ASIC and the daughtercard.

Good luck,

Robert

"We might have tried Dynamic Alignment once, but that was several SPI-4
core revisions ago. Otherwise, we've stuck with static alignment.

I haven't done any power measurements.  Xilinx has a spreadsheet that
can calculate power based on the actual design file (ncd).  But I bet
this is how
they came up with the 2Watt spec.

I am currently running the SPI cores (rx and tx) at 296MHz, which is
592MBit double data rate. We ran previously at 320MHz (640Mbit DDR),
but we were getting occasional SPI-4 DIP4 errors.
Even at the 296MHz rate, we've had to turn off the training patterns
that we send to the ASIC to get rid of SPI-4 framing errors.  Sounds
like
it has difficulty distinguishing between data frames and training
patterns sometimes.

Adding dynamic alignment would not fix this, because that only applies
to the rx core.  I wonder if going through the BGA connector is
aggravating the
problem.  We haven't spent much time debugging this issue, because the
296MHz clock rate is sufficient for now."


"Dan Schaffer" <dan-schaffer@comcast.net> wrote in message
news:nwrub.236601$Tr4.696017@attbi_s03...
> Has Anyone used the SPI 4.2 Core?
> How well is it implemented?
> Any idea of the power consumption? I'm wondering if the 2W specs on
the web
> site are valid.
>
> Thanks,
> Dan
>
>



Article: 63265
Subject: Re: Thank you all for the replays.
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 19 Nov 2003 16:12:40 +1300
Links: << >>  << T >>  << A >>
Valentin Tihomirov wrote:
> 
> I've got information that the CPLD uses 50k bus-holding feature. I've used
> 12k resistor in my reseting circuit instead of 130k and this solved the
> problem. However, I turrend bus keeping off in WebPack->fitter option. It is
> obusfucating. 3.3v*130/(130+50) = 2.35v I was getting when my 130k was
> pulling reset down and CPLD's keeper feature pulled it up with 50k.
> One thing I still do not understand is why 3.3v CPLD pulls up input to 2.4v.

Pinkeepers are not true resistors, but are weak N FETS (reason of
smallest die area ) They seem to make the pinkeeps using N+N FETS,
rather than N+PFETS,and the pullup is the N Source follower, so you
get a G-S drop, or appx 0.9V of threshold.
Put your meter from Pin-3.3V, and it will read 0.0V,
Put it from Pin-GND, and it reads 2.4V.
 Atmel CPLD data has curves of the I-V for pinkeeps that makes
this clearer.

-jg

Article: 63266
Subject: Re: Anyone use HDL as design tool for PCBs?
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Wed, 19 Nov 2003 14:38:59 +1100
Links: << >>  << T >>  << A >>
On Tue, 18 Nov 2003 17:49:24 -0800, "Symon" <symon_brewer@hotmail.com>
wrote:

>Hi,
>   Does anyone out there in usenet-land know of tools to let you design
>Printed Circuit Boards with VHDL? I'm ready to switch from schematic entry,
>I want portability! (And all the other good reasons I switched from
>schematic entry for my FPGA designs) Anyone use a PCB layout tool that
>accepts EDIF files? I see there are translator tools. Anyone ready to share
>their experiences, pitfalls et cetera?

Features like pin swapping, gate swapping and cross probing will only
work with a tightly integrated pcb and "source" toolset.

I suspect you would lose this with an HDL front end, although they do
seem possible in theory.


Frankly, the thought of designing a switchmode power supply using an
HDL scares me.  Designing a microstrip filter using an HDL seems nigh
on impossible.
(Hint: both these applications require careful layout, which is
something that can be more easily expressed with a graphical entry
tool.)

Regards,
Allan.

Article: 63267
Subject: Re: Transforming vector position to binary value
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Wed, 19 Nov 2003 03:48:29 GMT
Links: << >>  << T >>  << A >>
I can't agree with you on this.  I fail to see how what you wrote could be
offensive, nor do I see how anyone who's in the FPGA world could conclude or
extrapolate that something is being said about the quality of Xilinx's app
notes.  But, then again, I'm biased, I use their chips and love them.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"





"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message
news:bpcpim$5v3$1$8300dec7@news.demon.co.uk...
> I owe some folk an apology.
>
> "Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in
> message news:bovsnb$6o5$1$830fa7b3@news.demon.co.uk...
>
> > Don't be silly; if it's in a Xilinx appnote, it's _ipso facto_
> > conventional :-)
>
> When I wrote that, my intent was only to poke mild fun at
> the fact that Xilinx appnotes are such a pervasive part
> of the FPGA design culture that they almost *define* what's
> conventional.  But I didn't write it very well, and it was
> misunderstood as a slur on the quality of Xilinx material.
> That would have been quite absurd and I unreservedly
> apologise for any offence.
>
> Xilinx apps people have done us all a great service over
> the years by sharing a huge variety of tips and techniques
> (some conventional, some highly creative).  I've had many
> occasions to be grateful for that.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW,
UK
> Tel: +44 (0)1425 471223                    mail:
jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
>
>
>



Article: 63268
Subject: Re: Active-HDL 6.1 pricing
From: "Valeri Serebrianski" <serebr777@yahoo.com>
Date: Wed, 19 Nov 2003 10:09:39 +0600
Links: << >>  << T >>  << A >>

"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:h2klrvs2rsdl9r2s3co2slnmp0kh7kvl66@4ax.com...
> On Tue, 18 Nov 2003 22:02:59 +0200, "Valentin Tihomirov"
> <valentin@abelectron.com> wrote:
>
> >Downlad a trial from Altec. This prevents you from ascking stupd
questions.
>
> Was that directed at me or Rick?  Which questions were "stupd" ?
>
> Allan.

Hi Allan,

Your thread is quite informative. Don't pay attention to such rough letters.

Valeri.



Article: 63269
Subject: Re: Anyone use HDL as design tool for PCBs?
From: "Matt" <bielstein2002@comcast.net>
Date: Wed, 19 Nov 2003 04:18:03 GMT
Links: << >>  << T >>  << A >>
Hi Allan,

I tend to agree with your opinions. I just wanted to add that PCB layout
tools that generate VHDL/Verilog netlists are very useful for system level
simulation. Obviously this is not the information the original post was
attempting to obtain but I wanted to throw it out there for others to
contemplate.

Matt


"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:o0plrvk7kvd3mm2evhd0fr6nd1kdu26d3e@4ax.com...
> On Tue, 18 Nov 2003 17:49:24 -0800, "Symon" <symon_brewer@hotmail.com>
> wrote:
>
> >Hi,
> >   Does anyone out there in usenet-land know of tools to let you design
> >Printed Circuit Boards with VHDL? I'm ready to switch from schematic
entry,
> >I want portability! (And all the other good reasons I switched from
> >schematic entry for my FPGA designs) Anyone use a PCB layout tool that
> >accepts EDIF files? I see there are translator tools. Anyone ready to
share
> >their experiences, pitfalls et cetera?
>
> Features like pin swapping, gate swapping and cross probing will only
> work with a tightly integrated pcb and "source" toolset.
>
> I suspect you would lose this with an HDL front end, although they do
> seem possible in theory.
>
>
> Frankly, the thought of designing a switchmode power supply using an
> HDL scares me.  Designing a microstrip filter using an HDL seems nigh
> on impossible.
> (Hint: both these applications require careful layout, which is
> something that can be more easily expressed with a graphical entry
> tool.)
>
> Regards,
> Allan.



Article: 63270
Subject: Does anyone know anything about DC-FPGA?
From: apolloxie@hotmail.com (apple)
Date: 18 Nov 2003 21:42:41 -0800
Links: << >>  << T >>  << A >>
Where can i get the information about DC-FPGA?
I've searched Synopsys website, but got nothing :(

Article: 63271
Subject: Re: Acek 1K - Quartus II - timing issues
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 19 Nov 2003 01:06:12 -0500
Links: << >>  << T >>  << A >>
If you are going to play with the seed, you need to try several settings
before you can say it won't work.  

I once worked on a real b--ch of a design and my coworker set up a
script that would run multiple passes overnight.  That was the only way
we ever got the thing working.  he also had to write AWK scripts to
parse the timing results since this was MaxPlus2 and the thing pretty
well sucked for timing analysis.  I believe Quartus is much better now. 
But it left a bad taste in my mouth for Altera software.  I'll get over
it some day...


Kumaran wrote:
> 
> Hi Manfred,
> Thanks for your response. I am using the dedicated clock pin 79. I had
> a look at other threads for optimizing the speed. Some one mentioned
> that by increasing the seed in the fitter setting might increase the
> speed, but, they also mentioned that there will only be a slight
> improvement, and I saw a slight increase in the speed(not good
> enough). Any other suggestions? Thanks for your time.
> 
> Thanks,
> Kumaran
> 
> "Manfred Balik" <e8825130@stud4.tuwien.ac.at> wrote in message news:<3fb9d94f$0$18702$3b214f66@tunews.univie.ac.at>...
> > It looks like you didn't use the internal Clock-Network.
> > Use the dedicated Clock Pins 79 or 183 (and maybe the internal PLL) to have
> > the same delays of clock signal to each gate.
> > Manfred
> >
> >
> > "Kumaran" <kumaran@trlabs.ca> schrieb im Newsbeitrag
> > news:40f2d3e9.0311171247.ab73d04@posting.google.com...
> > > Hi all,
> > > I am targeting my design on Acex EP1K100QC208-3 FPGA. I did most of my
> > > development using Leonardo Spectrum synthesizer(2002) and Max +2. My
> > > license for leonardo expired, and I decided to use Quartus II(v3.0).
> > > When I compile using Quartus, Iam getting a negative slack time for
> > > one of my clock. when I compiled the same FPGA code using LS and Max
> > > +2, I did not have any timing issues . In the compiler settings, I
> > > have enabled the "optimize i/o cell register placement for timing"
> > > option. I also tried different synthesis tool in quartus (FPGA
> > > express, LS,..) but I could not get the timing right. Can anyone help
> > > me?
> > >
> > > Thanks,
> > >
> > > Kumaran

-- 

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: 63272
Subject: Re: Active-HDL 6.1 pricing
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 19 Nov 2003 01:09:25 -0500
Links: << >>  << T >>  << A >>
There are plenty of us who would like to use a nice low cost tool such
as this, if it works well.  Please keep us informed of any issues you
find.  


Peter Sommerfeld wrote:
> 
> Hi Allan,
> 
> Have you looked at Symphony EDA? It is 10% of Aldec's cost. I use
> Aldec, but Symphony looks promising to me (I started using it a week
> ago). It's interface is very similar, but it does not have all the
> bells and whistles of Active-HDL.
> 
> -- Pete
> 
> Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<g62jrvopslpsj5tpdfmi978imnp7cuo9s2@4ax.com>...
> > On Mon, 17 Nov 2003 19:27:22 -0500, rickman <spamgoeshere4@yahoo.com>
> > wrote:
> >
> > >Have you looked at any of the open source tools?  Is that what Icarus
> > >is?  I am not familiar with them, but I know they exist.
> >
> > Yes, I am looking at commercial software because I am currently using
> > an open source tool (Icarus).
> >
> > My experience is that "open source" isn't necessarily the same as
> > "good quality" when applied to EDA tools - both the developer and the
> > user communities are just too small to achieve quality comparable with
> > commercial EDA tools (or Linux, for that matter).
> >
> > I wish that someone could prove me wrong!
> >
> > Regards,
> > Allan.

-- 

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: 63273
Subject: regarding clock routing
From: praveen@cg-coreel.com (praveen)
Date: 18 Nov 2003 22:26:10 -0800
Links: << >>  << T >>  << A >>
hi all,

i have no of  D flip flops cascaded now there are two ways clock can be routed.

1) in the direction of the data flow.
2) opposite to the direction of the data flow.

which of the above is good??

thanks in advance

rgds,
praveen

Article: 63274
Subject: SDRAM-Controller XAPP134
From: "Simone Winkler" <simone.winkler@gmx.at>
Date: Wed, 19 Nov 2003 08:54:44 +0100
Links: << >>  << T >>  << A >>
Hello!

Is anyone of you familiar with the Xilinx Application Note XAPP134?
(downloadable at http://direct.xilinx.com/bvdocs/appnotes/xapp134.pdf ,
ftp://ftp.xilinx.com/pub/applications/xapp/xapp134_vhdl.zip)

My questions are:
* From the system, you can control the SDRAM with commands that are defined
through data_addr_n, we_rn and AD[29:28].
When I set one command, does it have to be set back to zero afterwards and
when?
E.g. when I write, I first set the addr_wr command and the address, then the
data_wr command and the data, but afterwards, do I have to set everything
(including the AD-bus) back to zero? (because, also zeros stand for a
command).

* I am wondering what I have to do at the very beginning:
At first, I put a reset, and it takes some time until I can perform any
action.
Then I precharge and load the controller mode register (this has to be done
before anything else can be done, right?)
But then....? Do I have to load the SDRAM mode register before I can
read/write/auto refresh/...

* And did I understand right, that I still have to do the refresh by hand,
so every 64ms? By issueing the command AUTO REFRESH? Or does the controller
already do this for me?

* But now, finally the last question:
In the future, I need a 16-bit-wide-data-bus-design for a 32mb module
instead of the 32-bit-design that is given here. The data destination should
then be masked by the DQMs. How can I easily convert this?

Thank you VERY MUCH! :-)

Simone Winkler




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
2019JanFebMar2019

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