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 113575

Article: 113575
Subject: EDK, header file modified and problem
From: "Pasacco" <pasacco@gmail.com>
Date: 17 Dec 2006 08:33:03 -0800
Links: << >>  << T >>  << A >>
Hi
I am writing some C codes for Microblazes on EDK.
Problem is that

If I do not change the header file, it works fine.
But, when I modify some parameters (for example, #define, or in-line
function body ) in the user defiend header file,
the system does not work.

When I look at 'Directory' tab in "Compiler option",
"Search path" and "Linker option" are empty.
Only "Output information" contains the location of ELF file.

Can anyone point me out what I am missing?


Article: 113576
Subject: Re: FPGA : Async FIFO, Programmable full
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 17 Dec 2006 08:49:10 -0800
Links: << >>  << T >>  << A >>
Daniel, why do you want to avoid the Gray register? Your design is at
least as complicated and expensive, and incurs all this latency. Why do
it, when there are simpler ways to avoid it?
Peter Alfke

On Dec 17, 7:30 am, "Daniel S." <digitalmastrmind_no_s...@hotmail.com>
wrote:
> There is a simple way of avoiding "mysterious glitches" when using
> binary counters: freeze the counter in a second register in the first
> clock domain and do a one bit handshake across the two domains. Since
> the counter (copy) is frozen during the handshaking, the other clock
> domain's FFs will have ample setup time until the strobe propagates
> through the resync.
>
> With a fully resync'd handshake, this approach does introduce up to 3x
> clock1 + 1.5x clock2 cycles delay between update, which is certainly not
> suitable for low-latency and small high-speed FIFOs, especially if there
> is a large difference in clock speeds. It works well as long as one can
> live with long status delays for the first (read) and last (write) few
> FIFO words.
>
> The design is nice as long as clocks are of similar frequencies but the
> delay may become an issue for large read:write (and vice-versa) clock
> ratios. At 10:1, the status update may have a latency exceeding 40 fast
> clock cycles.
>
> So, binary counters can be safely used by using frozen copies and
> handshaking. The caveat is higher latency than gray counters due to
> handshaking and register copies that add extra dependencies upon the
> other clock domain.
>
> As always, designers are free to pick their poison.
>
> Peter Alfke wrote:
> > In an asynchronous FIFO, reading and writing is controlled by two
> > counters with independent clocks.
> > If you need to detect FULL or EMPTY, you compare the two counters for
> > identity.
> > If you do that with binary counters, you are vulnerable to strange
> > decoding glitches, while multiple binary bits change (almost, but not
> > quite, simultaneously). You never have that problem with Gray counters,
> > where only one bit changes, from one state to the next.
> > Peter Alfke
> > =============
> > RCIngham wrote:
> >>> There is a wrong way and a right way to convert binary to Gray count
> >>> values:
> >>> The wrong way hangs the (simple!) combinatorial conversion logic (XORs)
> >>> on the binary outputs. That does you no good, since the Gray code will
> >>> just reflect the binary transient errors.
> >>> The right way takes the D inputs of the binary counter (, converts them
> >>> independently to Gray and registers them in their own flip-flops. Now
> >>> you have two parallel rgisters, both counting in step, the first in
> >>> binary, the other in Gray, and there are no funny decoding spikes.
> >>> BTW, only Gray counter outputs have the feature that you can compare
> >>> two asynchronous counters for identity, without transient errors.
> >>> If the Gray code does not come from a counter, it might change multiple
> >>> bits per transition...
> >> <snip />
> >> Whether that is the right answer rather depends on WHY the OP "has" to use
> >> Gray Code, which is still not fully established.
>
> >> BTW, there is a quite interesting article on Gray Code just posted at:
> >>http://www.pldesignline.com/showArticle.jhtml?articleID=196604078


Article: 113577
Subject: Re: PowerPC_EDK to ISE
From: "Moti Cohen" <Moti.cohen@alvarion.com>
Date: 17 Dec 2006 08:54:46 -0800
Links: << >>  << T >>  << A >>

Vangelis wrote:
> I am trying to import a PowerPC design from EDK 7.1 to ISE 7.1 Project Navigator. While the design is working just fine when I download it from EDK, when I am trying to synthesize it in ISE and then download it to the FPGA nothing happens. It seems like the processor has no code to execute. In Project Navigator I generate the bitstream first and then I am updating the bitstream with processor data, just as the manual of the EDK mentions. Has anyone else the same problem?

It is most likely that the problem is in the .bmm file.
the ISE 7.1 places it in a wrong position, it should be related to your
top module.
Also make sure that the path to the memories inside the .bmm file is
correct.
I hope it helps..
Mordehay.


Article: 113578
Subject: Re: Frequency divider?
From: <222>
Date: Sun, 17 Dec 2006 17:30:24 -0000
Links: << >>  << T >>  << A >>
> > The short answer is 'NO'
> >
> > I can see a few issues. Do you need a 50% duty cycle on the output
> > clock? That would bring up another issue.

Can you please explain why I will not have 50% duty cycle?

> >
> > I'll be generous and assume this is not homework, but if it is, realise

No.

> > you're not really learning anything if you don't make your own mistakes;
> > that way the lesson sticks ;)
> >
> >
> > //divide oscillator clock by 10 (xc9536)
> > module clk_div10 (in,out)
> > input in; // input clock
> > output out; // output clock = input/10
> > reg[0..3] cnt;
> >
> > assign out = cnt[3];     // map MSB to output - previous code
> > needed a reg statement, which may or may not have been absorbed.

Please explain, what is the purpose of this?

> > // always @ (in)
> > always @ (posedge in) // use the edge. The previous statement was
> > a                     //static sensitivity list, as used in
> >             // combinational assignments

Please explain why I should use the edge-trigger logic rather than
combinational statements?


> > begin
> > //     cnt=cnt+1;    // let's not use a blocking assignment
> >
> // >     if (cnt[3] & (cnt[2:0]))    // test for increment
> if (cnt[3] & (&cnt[2:0]))    // test for increment - fixed
> > or                             // reset at top
> >         begin
> >          cnt <= 4'b0;     // count == 9 normally, and

What is happening here, why are you testing up to 4 and not 9 ?


> > also                         //guarantees
> >             // to move the counter to a valid state if it
> >             // somehow was in the range of 10 - 15
> >             // Also need to tell some tools explicitly
> >             // about the number of 0s
> >             // I also added a little trickery to the test
> >             // which you will need to understand if you are
> >             // presenting this as homework ;)
> >         end
> >      else begin        // just increment
> >     cnt <= cnt+1;
> >      end
> > end
> >  endmodule
> >
> >
> > I did a number of things, as you can see - now figure out why :)
> >
> >
> > If you want a 50% duty cycle, it's a different matter.
> >
> > Cheers
> >
> > PeteS
>
> One fix in the test - more coffee!!!



Article: 113579
Subject: Re: electrical level conversion
From: Austin <austin@xilinx.com>
Date: Sun, 17 Dec 2006 11:01:32 -0800
Links: << >>  << T >>  << A >>
Brian,

The specification is min 3pF; max 10 pF for 3E.

Austin

Brian Davis wrote:
> John Larkin wrote:
> 
>>I might modestly suggest that my little circuit shifts the DC level
>>down, reduces the AC swing, terminates the differential trace
>>impedance, furnishes the pecl pulldown current, and presents the same
>>clean square wave to both fpga clocks, all independent of trace
>>lengths.
>>
> 
>  One caution, most Xilinx LVDS inputs have a Cin of around 8-12 pF
> (single ended), which will cause horrible {re}reflections when driven
> directly in a multidrop topology from a fast ECL driver- unless those
> MGT clock inputs have much better Cin than the regular LVDS inputs.
> 
>  Given the physical size of an FX60 package, there's likely to be
> enough distance between the two inputs to create a ledge or
> double clock with both inputs hanging off of the same net like that.
> 
>  The fanout buffer is probably the best solution, but if I had to make
> it work driving two 10 pF inputs with internal Rterm from a single net,
> I'd probably try series R's at each clock input to form a higher
> impedance line tap/divider coupling a portion of the signal off of an
> externally end-terminated net.
> 
> other related FPGA LVDS notes:
> 
>  - Spartan 3E LVDS inputs have a much improved Cin of around 3 pF
> 
>  - Xilinx common mode input range with internal terminations:
>        Although the LVDS inputs WITHOUT internal termination have
>      a wide common mode range, the internally terminated variants
>      (DIFF_TERM, DT) apparently are restricted to the much narrower
>      common mode range of the associated differential OUTPUT standard
>      to meet the specified internal termination tolerance
> 
>  - resistive ECL level shifts for solitary FPGA LVDS inputs:
>       When driving a single LVDS input, I usually use something like
>     Fig. 15 of AN1568, which creates the shift with a tapped pulldown:
>     -   http://www.onsemi.com/pub/Collateral/AN1568-D.PDF
> 
>        Plus additional provision for a series Rs from each junction,
>      letting you tweak the back termination to match the line.
> 
>        Those resistors can then all be placed right at the driver,
>      far, far away from the cluttered BGA breakout pattern, with
>      the typical LVDS 100 ohm Rdiff at the receiver input.
> 
> Brian
> 

Article: 113580
Subject: Re: Frequency divider?
From: tersono <ethel.thefrog@ntlworld.com>
Date: Sun, 17 Dec 2006 19:39:34 GMT
Links: << >>  << T >>  << A >>

Here's my half-penny's worth:

########################
module div10(in,out);
input in;
output out;

//put your ratio in here
`define RATIO 10

// need 4 regs, because three will only give 8 states
reg [3:0]Q;

//  at each rising edge of clock
always @(posedge in)

// if Q=9, next state is 0, else Q<=Q+1
Q<=(Q==`RATIO-1)?4'b0:Q+1;

assign out=Q[3];

endmodule
########################

The above counts 0 1 2 ...7 8 9

Output is high 2 states in 10 -states 8 and 9 so not 1:1ratio

If you want 1:1 ratio

########################
module div10(in,out);
input in;
output out;

//put your ratio in here
`define RATIO 10

// need 4 regs, because three will only give 8 states
reg [3:0]Q;

reg out;

//  at each rising edge of clock
always @(posedge in)

begin
// if Q=9, next state is 0, else Q<=Q+1
Q<=(Q==`RATIO-1)?4'b0:Q+1;

// output high for states 5 6 7 8 9
out<=(Q>4);
end

endmodule
########################
--
Per ardua ad nauseam

Article: 113581
Subject: Re: electrical level conversion
From: "Brian Davis" <brimdavis@aol.com>
Date: 17 Dec 2006 12:01:10 -0800
Links: << >>  << T >>  << A >>
Austin wrote:
>
> The specification is min 3pF; max 10 pF for 3E.
>
 Try looking at the IBIS files, which show a total max Cin
( C_pkg plus C_comp ) of a mere 2.4 pF for a VQ100.

 Measured reflections off a fast LVDS driver in the lab
also agree with a Cin value in that range.

 Perhaps I should file a WebCase asking Xilinx to update
their datasheet to match their IBIS files :)

 Also, as I mentioned last April, detail for the different
pin types is also missing from the datasheet:

http://groups.google.com/group/comp.arch.fpga/msg/069c3ec4ec13de51
>
>  It's interesting to contrast the datasheet C values for the two
>families:
>
>Cyclone-II
>  Cio     6 pF (typ)    user I/O
>  Clvds   6 pF (typ)    user I/O with LVDS
>  Cvref  21 pF (typ)    user I/O with Vref function
>  Cclk    5 pF (typ)    global clock input
>
>Spartan-3E
>  Cin    3 pF (min) 10 pF (max)
>
>  Which makes no distinction between input only pins, I/O pins,
>global clock input pins, left/right side clock pins, dual mode
>config pins, Vref pins,  dedicated config pins, etc
>

Brian


Article: 113582
Subject: Re: Xilins ISE Re-Creating Projects
From: "marc_ely" <marc_ely@yahoo.co.uk>
Date: 17 Dec 2006 12:23:23 -0800
Links: << >>  << T >>  << A >>
Thanks for the responses.
CVS has saved me a couple of times already, but I find it astonishing
that this buggy garbage is out there.

Regards
Marc


Article: 113583
Subject: Re: PowerPC_EDK to ISE
From: Vangelis <>
Date: Sun, 17 Dec 2006 12:28:39 -0800
Links: << >>  << T >>  << A >>
The problem that I had is mentioned in the answer ##22205 in the Answer Record Database. I did what the answer says and I solved my problem. Thanks for the answers anyway!

Article: 113584
Subject: Re: DSP or FPGA for high-speed image processing?
From: Tim Wescott <tim@seemywebsite.com>
Date: Sun, 17 Dec 2006 12:41:57 -0800
Links: << >>  << T >>  << A >>
kyori wrote:

> Hi,
> 
> I am going to start a project of onboard high-speed CMOS image
> processing.
> I am goint to perform certain *block matching algorithm* or *Fourier
> Transform* between successive frames and the fps would be 1000 or
> more..
> 
> 
> The interface between the CMOS camera and the board is standord
> CamLink.
> I've learned that both DSP and FPGA based circuits can do certain
> onboard image processing tasks, and I'd like to know whick is better?
> DSP or FPGA?
> 
> 
> I know some corporations use FPGA based boards as development boards
> for their cameras. And my cooperators have some DSP development
> experiences. So, the question arises, and I want your suggestions. I'd
> like to know the advantages of each choise and maybe the direction of
> onboard realtime high-speed image processing.
> 
> 
> Thanks! 
> Any help would be appreciated.
> 
Please go to wikipedia and look up "cross post".  Compare what they have
to say about cross posting with what they have to say about multiple
posting.

Then do it right.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 113585
Subject: Re: FPGA : Async FIFO, Programmable full
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Sun, 17 Dec 2006 16:06:34 -0500
Links: << >>  << T >>  << A >>
What I want to avoid is the gray-to-binary conversion necessary to 
calculate population counts and flags afterwards.

The design only introduces a simple handshake and replaces the gray 
resync registers by copy (hold) registers to create a safe false path 
for data between clock domains. IMO, this is simpler than having to 
decode gray counters before computing differences.

Yes, that approach does sacrifice five extra FFs and some in-to-out 
latency for the handshaking in each direction (that could be reduced by 
using some async SR FFs) but it is a straight register-to-register 
design that enables direct pointer arithmetic on both sides. With gray 
counters, you end up needing a decoder for both local and remote 
counters on each side before doing arithmetic in each clock domain.

As I said, designers are free to pick their poison.

For most applications I have in mind (mostly DMA-like), I can afford to 
trade some latency and a few FFs for the ability to stick with a simple, 
plain binary register-to-register and decoder-less design.

BTW, unless the gray decoders are fully absorbed by the arithmetic at no 
performance cost (doesn't gray code kill the carry chains?), my 
implementation should use fewer LUTs and be able to clock higher.

Peter Alfke wrote:
> Daniel, why do you want to avoid the Gray register? Your design is at
> least as complicated and expensive, and incurs all this latency. Why do
> it, when there are simpler ways to avoid it?
> Peter Alfke
> 
>> So, binary counters can be safely used by using frozen copies and
>> handshaking. The caveat is higher latency than gray counters due to
>> handshaking and register copies that add extra dependencies upon the
>> other clock domain.
>>
>> As always, designers are free to pick their poison.

Article: 113586
Subject: Re: Frequency divider?
From: <222>
Date: Sun, 17 Dec 2006 21:07:51 -0000
Links: << >>  << T >>  << A >>

"tersono" <ethel.thefrog@ntlworld.com> wrote in message
news:ff6bo29ov2ee3j9e30qkge4skuqt9hru9t@4ax.com...
>
> Here's my half-penny's worth:
>
> ########################
> module div10(in,out);
> input in;
> output out;
>
> //put your ratio in here
> `define RATIO 10
>
> // need 4 regs, because three will only give 8 states
> reg [3:0]Q;
>
> //  at each rising edge of clock
> always @(posedge in)
>
> // if Q=9, next state is 0, else Q<=Q+1
> Q<=(Q==`RATIO-1)?4'b0:Q+1;
>
> assign out=Q[3];
>
> endmodule
> ########################
>
> The above counts 0 1 2 ...7 8 9
>
> Output is high 2 states in 10 -states 8 and 9 so not 1:1ratio
>
> If you want 1:1 ratio
>
> ########################
> module div10(in,out);
> input in;
> output out;
>
> //put your ratio in here
> `define RATIO 10
>
> // need 4 regs, because three will only give 8 states
> reg [3:0]Q;
>
> reg out;
>
> //  at each rising edge of clock
> always @(posedge in)
>
> begin
> // if Q=9, next state is 0, else Q<=Q+1
> Q<=(Q==`RATIO-1)?4'b0:Q+1;
>
> // output high for states 5 6 7 8 9
> out<=(Q>4);
> end

I don't like this notation, it forces me to delve deep into C-like syntax
which focuses my mind away from hardware, but everyone and their
own styles.


>
> endmodule
> ########################
> --
> Per ardua ad nauseam



Article: 113587
Subject: Re: electrical level conversion
From: Austin <austin@xilinx.com>
Date: Sun, 17 Dec 2006 13:18:26 -0800
Links: << >>  << T >>  << A >>
Brian,

I will look into that.  From what I know about the design, the only way 
to reduce the C is to leave out the LVDS output driver (0.5pF less), or 
make the IO drive strength smaller.  Until we drop the high output 
standards, the C is unlikely to get any smaller (just physics of a 
general purpose pin).  It may be that 3E drops some of these (I will check).

The Vref pins do not have any more load, until they are programmed to be 
a Vref, so we do not specify their C as a Vref (as the recommendation is 
to put a 0.1uF as close as possible to the Vref pin anyway).

Sometimes a missing specification is just something not needed.

But, if you filed it as a case, you should have received a reply as to 
why the specification did not require an update.  Case #?

Austin


> Austin wrote:
> 
>>The specification is min 3pF; max 10 pF for 3E.
>>
> 
>  Try looking at the IBIS files, which show a total max Cin
> ( C_pkg plus C_comp ) of a mere 2.4 pF for a VQ100.
> 
>  Measured reflections off a fast LVDS driver in the lab
> also agree with a Cin value in that range.
> 
>  Perhaps I should file a WebCase asking Xilinx to update
> their datasheet to match their IBIS files :)
> 
>  Also, as I mentioned last April, detail for the different
> pin types is also missing from the datasheet:
> 
> http://groups.google.com/group/comp.arch.fpga/msg/069c3ec4ec13de51
> 
>> It's interesting to contrast the datasheet C values for the two
>>families:
>>
>>Cyclone-II
>> Cio     6 pF (typ)    user I/O
>> Clvds   6 pF (typ)    user I/O with LVDS
>> Cvref  21 pF (typ)    user I/O with Vref function
>> Cclk    5 pF (typ)    global clock input
>>
>>Spartan-3E
>> Cin    3 pF (min) 10 pF (max)
>>
>> Which makes no distinction between input only pins, I/O pins,
>>global clock input pins, left/right side clock pins, dual mode
>>config pins, Vref pins,  dedicated config pins, etc
>>
> 
> 
> Brian
> 

Article: 113588
Subject: Re: electrical level conversion
From: "Brian Davis" <brimdavis@aol.com>
Date: 17 Dec 2006 14:24:41 -0800
Links: << >>  << T >>  << A >>
Austin wrote:
>
> From what I know about the design, the only way to reduce
> the C is to leave out the LVDS output driver (0.5pF less), or
> make the IO drive strength smaller. <snip>
> It may be that 3E drops some of these (I will check).
>
 The simplified S3E I/O drops DCI and some of the higher
drive standards vs. S3, and adds DIFF_TERM support.

>
>>  Which makes no distinction between input only pins, I/O pins,
>> global clock input pins, left/right side clock pins, dual mode
>> config pins, Vref pins,  dedicated config pins, etc.
>
> The Vref pins do not have any more load, until they are programmed
> to be a Vref, so we do not specify their C as a Vref  <snip>
>
> Sometimes a missing specification is just something not needed.
>
 Some inputs, such as global clocks or the MGT clock inputs of this
thread, are likely to differ from general I/O, but are not documented
as such in that single datasheet spec, nor in the IBIS files.

>
> >  Perhaps I should file a WebCase asking Xilinx to update
> > their datasheet to match their IBIS files :)
>
> But, if you filed it as a case, you should have received a reply as to
> why the specification did not require an update.  Case #?
>
  If the "perhaps" and the smiley didn't give it away,
that was intended as a humorous observation for those
of us who have filed WebCases.

Brian


Article: 113589
Subject: Re: electrical level conversion
From: "Michael A. Terrell" <mike.terrell@earthlink.net>
Date: Sun, 17 Dec 2006 22:40:31 GMT
Links: << >>  << T >>  << A >>
Brian Davis wrote:
> 
> Austin wrote:
> >
> > From what I know about the design, the only way to reduce
> > the C is to leave out the LVDS output driver (0.5pF less), or
> > make the IO drive strength smaller. <snip>
> > It may be that 3E drops some of these (I will check).
> >
>  The simplified S3E I/O drops DCI and some of the higher
> drive standards vs. S3, and adds DIFF_TERM support.
> 
> >
> >>  Which makes no distinction between input only pins, I/O pins,
> >> global clock input pins, left/right side clock pins, dual mode
> >> config pins, Vref pins,  dedicated config pins, etc.
> >
> > The Vref pins do not have any more load, until they are programmed
> > to be a Vref, so we do not specify their C as a Vref  <snip>
> >
> > Sometimes a missing specification is just something not needed.
> >
>  Some inputs, such as global clocks or the MGT clock inputs of this
> thread, are likely to differ from general I/O, but are not documented
> as such in that single datasheet spec, nor in the IBIS files.
> 
> >
> > >  Perhaps I should file a WebCase asking Xilinx to update
> > > their datasheet to match their IBIS files :)
> >
> > But, if you filed it as a case, you should have received a reply as to
> > why the specification did not require an update.  Case #?
> >
>   If the "perhaps" and the smiley didn't give it away,
> that was intended as a humorous observation for those
> of us who have filed WebCases.
> 
> Brian


  Are you the Brian Davis that workled for Microdyne?


-- 
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

Article: 113590
Subject: Re: electrical level conversion
From: Austin <austin@xilinx.com>
Date: Sun, 17 Dec 2006 14:54:27 -0800
Links: << >>  << T >>  << A >>
Brian,

That would make sense (dropping a low voltage strong standard reduces 
pin C).  Dropping DCI would hardly save anything except area, however.

I will take it that you did not file a webcase.  With a webcase number, 
it could be tracked and solved, or escalated (and solved).  Or even 
reported to myself or Peter (as some have done).

Now that Spartan has "grown up", they are making their own decisions as 
to what to spend their silicon on, so I have lost track of some of their 
features.  I should not have replied for them, as I really don't know 
what they are doing (without asking).

Austin


Brian Davis wrote:

> Austin wrote:
> 
>>From what I know about the design, the only way to reduce
>>the C is to leave out the LVDS output driver (0.5pF less), or
>>make the IO drive strength smaller. <snip>
>>It may be that 3E drops some of these (I will check).
>>
> 
>  The simplified S3E I/O drops DCI and some of the higher
> drive standards vs. S3, and adds DIFF_TERM support.
> 
> 
>>> Which makes no distinction between input only pins, I/O pins,
>>>global clock input pins, left/right side clock pins, dual mode
>>>config pins, Vref pins,  dedicated config pins, etc.
>>
>>The Vref pins do not have any more load, until they are programmed
>>to be a Vref, so we do not specify their C as a Vref  <snip>
>>
>>Sometimes a missing specification is just something not needed.
>>
> 
>  Some inputs, such as global clocks or the MGT clock inputs of this
> thread, are likely to differ from general I/O, but are not documented
> as such in that single datasheet spec, nor in the IBIS files.
> 
> 
>>> Perhaps I should file a WebCase asking Xilinx to update
>>>their datasheet to match their IBIS files :)
>>
>>But, if you filed it as a case, you should have received a reply as to
>>why the specification did not require an update.  Case #?
>>
> 
>   If the "perhaps" and the smiley didn't give it away,
> that was intended as a humorous observation for those
> of us who have filed WebCases.
> 
> Brian
> 

Article: 113591
Subject: Re: FPGA : Async FIFO, Programmable full
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 17 Dec 2006 14:55:02 -0800
Links: << >>  << T >>  << A >>
Maybe this is getting too long in the tooth.
For B-to-G conversion use the D input of the binary counter, so it adds
only one LUT delay, irrespective of length.
There is no G-to-B conversion, because I derived the Gray code from the
binary.
Maybe this is getting too complex for just a short e-mail.
My idea is: Do all the math in binary, convert to Gray in a synchronous
transfer that does NOT add any latency, do the identity comparison
between clock domains in Gray, then add some ciruitry to combat
metastability.
But, as I mentioned before, I never had the luxury of designing for a
single-point solution.
BTW, if you want to check existing patents, now you can use:
www.google.com/patents. Very nice!
Peter Alfke

On Dec 17, 1:06 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com>
wrote:
> What I want to avoid is the gray-to-binary conversion necessary to
> calculate population counts and flags afterwards.
>
> The design only introduces a simple handshake and replaces the gray
> resync registers by copy (hold) registers to create a safe false path
> for data between clock domains. IMO, this is simpler than having to
> decode gray counters before computing differences.
>
> Yes, that approach does sacrifice five extra FFs and some in-to-out
> latency for the handshaking in each direction (that could be reduced by
> using some async SR FFs) but it is a straight register-to-register
> design that enables direct pointer arithmetic on both sides. With gray
> counters, you end up needing a decoder for both local and remote
> counters on each side before doing arithmetic in each clock domain.
>
> As I said, designers are free to pick their poison.
>
> For most applications I have in mind (mostly DMA-like), I can afford to
> trade some latency and a few FFs for the ability to stick with a simple,
> plain binary register-to-register and decoder-less design.
>
> BTW, unless the gray decoders are fully absorbed by the arithmetic at no
> performance cost (doesn't gray code kill the carry chains?), my
> implementation should use fewer LUTs and be able to clock higher.
>
> Peter Alfke wrote:
> > Daniel, why do you want to avoid the Gray register? Your design is at
> > least as complicated and expensive, and incurs all this latency. Why do
> > it, when there are simpler ways to avoid it?
> > Peter Alfke
>
> >> So, binary counters can be safely used by using frozen copies and
> >> handshaking. The caveat is higher latency than gray counters due to
> >> handshaking and register copies that add extra dependencies upon the
> >> other clock domain.
> 
> >> As always, designers are free to pick their poison.


Article: 113592
Subject: Re: FPGA : Async FIFO, Programmable full
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Sun, 17 Dec 2006 21:02:19 -0500
Links: << >>  << T >>  << A >>
Yes, one can do "ptrA == ptrB" directly in gray... but if I want to do 
"ptrA - ptrB" to know how much headroom I have, it does not work quite 
as nicely, this does require G2B conversion.

For a gray implementation, it is probably preferable to generate a 
straight gray counter and convert that to linear binary for local use to 
avoid combinational paths and routing between the counter's registers 
and the other domain's resync registers since it increases the risk 
transcoding glitches (path delays + non-existing phase relation + ...) 
getting through. With a binary counter, the gray conversion must be 
registered on the local clock before resyncing to the other clock.

In any case, the most important point of any design always is: it has to 
work.

Peter Alfke wrote:
> Maybe this is getting too long in the tooth.
> For B-to-G conversion use the D input of the binary counter, so it adds
> only one LUT delay, irrespective of length.
> There is no G-to-B conversion, because I derived the Gray code from the
> binary.
> Maybe this is getting too complex for just a short e-mail.
> My idea is: Do all the math in binary, convert to Gray in a synchronous
> transfer that does NOT add any latency, do the identity comparison
> between clock domains in Gray, then add some ciruitry to combat
> metastability.
> But, as I mentioned before, I never had the luxury of designing for a
> single-point solution.
> BTW, if you want to check existing patents, now you can use:
> www.google.com/patents. Very nice!
> Peter Alfke
> 
> On Dec 17, 1:06 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com>
> wrote:
>> What I want to avoid is the gray-to-binary conversion necessary to
>> calculate population counts and flags afterwards.
>>
>> The design only introduces a simple handshake and replaces the gray
>> resync registers by copy (hold) registers to create a safe false path
>> for data between clock domains. IMO, this is simpler than having to
>> decode gray counters before computing differences.
>>
>> Yes, that approach does sacrifice five extra FFs and some in-to-out
>> latency for the handshaking in each direction (that could be reduced by
>> using some async SR FFs) but it is a straight register-to-register
>> design that enables direct pointer arithmetic on both sides. With gray
>> counters, you end up needing a decoder for both local and remote
>> counters on each side before doing arithmetic in each clock domain.

Article: 113593
Subject: Re: JTAG programming of Altera Cyclone and CONF_DONE
From: Mark McDougall <markm@vl.com.au>
Date: Mon, 18 Dec 2006 14:09:01 +1100
Links: << >>  << T >>  << A >>
Marc Guardiani wrote:

> Check to make sure that you have pullups on nCONFIG, CONFIG_DONE, and
> nSTATUS. Passive serial configuration devices provide these pullups by
> default, which could be missing on the board. Removing the configuration
> device would remove the pullups, preventing configuration even from JTAG.

Yes, there is (10k), which is why I'm scratching my head! :O

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 113594
Subject: Re: Xilins ISE Re-Creating Projects
From: "johnp" <johnp3+nospam@probo.com>
Date: 17 Dec 2006 19:23:27 -0800
Links: << >>  << T >>  << A >>
I believe the original files were ASCII.   The new binary .ise format
is an "improvement".  I think this was a huge mistake, the project
file should be text - easily archived, documented, modified, etc.  The
binary file =is a nightmare for users.

John Providenza




David M. Palmer wrote:
> In article <1166196746.946286.260300@n67g2000cwd.googlegroups.com>,
> marc_ely <marc_ely@yahoo.co.uk> wrote:
>
> > The project file corruptions seem to occur randomly and will do various
> > things, such as remove all files from the project (and not let you add
> > them back), or not let you edit coregen parts, or a host of other
> > things.
> >
> > Re-creating a project each time seems very laborious.  Does anyone have
> > any shortcuts to do this?  Is there a TCL script that can be run?
> > Archiving and Project Cleanup don't help.
>
> In general:
>
> a) Use a good version control system, such as CVS or SVN, and then
> revert to a good version whenever you run into corruption
> or
> b) Save a copy of the project when it is working, and then copy it back
> when things stop working.
>
>
> a) is what you should do.  b) is what you will do now that I've
> suggested it.  a) is what you will eventually do.
>
> > Why can't they just implement project files as text files and let you
> > control them by hand?
>
> Because they haven't yet learned the lesson that ISE designers tend to
> learn eventually.  Text file project definitions always rise to the top
> of the users' wish list eventually, even though it is initially easier
> for the tool developers to just write() the binary structures into a
> file.
>
> --
> David M. Palmer  dmpalmer@email.com (formerly @clark.net, @ematic.com)


Article: 113595
Subject: Re: what are your current SoC design for ?
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Sun, 17 Dec 2006 23:46:13 -0500
Links: << >>  << T >>  << A >>
rponsard@gmail.com wrote:
> I don't need your IP secrecies...
> 
> This is for my students : what, in your current design, requires using
> a fpga + softcore, in place of a COTS micro controler ?
> less IC -> lower footprint, lower power cons., parallelism,...
> 
> thanks,
> raph
> 

Fewer ICs? Yes - why have a $3 I2C PROM and a $5 microcontroller with 
the extra manufacturability programming bother when they can be emulated 
using a spare BRAM or two and 200 slices in a $40 FPGA that's already 
there for high-bandwidth signal processing?

Lower power? Yes - sort of: more in the form of not needing an extra 
power regulator, clock source and other such items for the external 
microcontroller

Parallelism? No - a soft core sounds like a pretty lousy choice for pure 
software parallelism... you might need to fill an XC5V330LX with 
microblazes to match modern CPUs. High-performance algorithms in FPGAs 
are much better served with pipelined parallelized logic implementations.

Other reasons?
- Cost: if the microcontroller core fits, it is practically free
- Cost: an integrated microcontroler does not need IOs to interface with 
internal logic
- Simplicity: an integrated microcontroller is easier to interface (no 
need to manage tristate IOs)
- Simplicity: an integrated microcontroller can be customized
- Simplicity: auxiliary microcontroller functions can be implemented in 
logic
- Flexibility: all of the above
- Flexibility: No compromising with multi-function pins
- Performance, bandwidth, latency, etc.
- If I had time, I could probably list over 100 reasons

I have often been very frustrated with multi-function pins on 
off-the-shelf chips where two features I want often end up being 
mutually exclusive on most reasonably sized devices. With soft cores, 
nobody ever has to face this irritating limitation of hard-wired logic.

Article: 113596
Subject: Re: FPGA : Async FIFO, Programmable full
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 17 Dec 2006 20:53:26 -0800
Links: << >>  << T >>  << A >>
Let's leave it at that. We won't agree, but then: we do not have to...
Peter Alfke
BTW, Google lists over 1000 patents on FIFOs.
A few of them are mine, but I could not believe the total number...

On Dec 17, 6:02 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com>
wrote:
> Yes, one can do "ptrA == ptrB" directly in gray... but if I want to do
> "ptrA - ptrB" to know how much headroom I have, it does not work quite
> as nicely, this does require G2B conversion.
>
> For a gray implementation, it is probably preferable to generate a
> straight gray counter and convert that to linear binary for local use to
> avoid combinational paths and routing between the counter's registers
> and the other domain's resync registers since it increases the risk
> transcoding glitches (path delays + non-existing phase relation + ...)
> getting through. With a binary counter, the gray conversion must be
> registered on the local clock before resyncing to the other clock.
>
> In any case, the most important point of any design always is: it has to
> work.
>
> Peter Alfke wrote:
> > Maybe this is getting too long in the tooth.
> > For B-to-G conversion use the D input of the binary counter, so it adds
> > only one LUT delay, irrespective of length.
> > There is no G-to-B conversion, because I derived the Gray code from the
> > binary.
> > Maybe this is getting too complex for just a short e-mail.
> > My idea is: Do all the math in binary, convert to Gray in a synchronous
> > transfer that does NOT add any latency, do the identity comparison
> > between clock domains in Gray, then add some ciruitry to combat
> > metastability.
> > But, as I mentioned before, I never had the luxury of designing for a
> > single-point solution.
> > BTW, if you want to check existing patents, now you can use:
> >www.google.com/patents. Very nice!
> > Peter Alfke
>
> > On Dec 17, 1:06 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com>
> > wrote:
> >> What I want to avoid is the gray-to-binary conversion necessary to
> >> calculate population counts and flags afterwards.
>
> >> The design only introduces a simple handshake and replaces the gray
> >> resync registers by copy (hold) registers to create a safe false path
> >> for data between clock domains. IMO, this is simpler than having to
> >> decode gray counters before computing differences.
>
> >> Yes, that approach does sacrifice five extra FFs and some in-to-out
> >> latency for the handshaking in each direction (that could be reduced by
> >> using some async SR FFs) but it is a straight register-to-register
> >> design that enables direct pointer arithmetic on both sides. With gray
> >> counters, you end up needing a decoder for both local and remote
> >> counters on each side before doing arithmetic in each clock domain.


Article: 113597
Subject: Re: Frequency divider?
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Sun, 17 Dec 2006 23:58:49 -0500
Links: << >>  << T >>  << A >>
222 wrote:
>>> Correction, this is wrong
>>>          out =out +1;
>>> Put this in instead
>>>         out =!out
>>>
>>>
>> Since you toggle "out" every time your counter reaches 10, you are
>> actually creating a waveform with twice the period you intended. Also,
> 
> Does "always @(x)" work on _any_ change, i.e. it should react twice
> on each clock, which would make it right, or does it default to positive
> edge,
> which would make it twice the period?

As I said, I have only poked into verilog with a pole... I overlooked 
that little detail and yes, this does appear to be equivalent to 
clk'event in VHDL.

In this case, try synthesizing your code with free tools from most FPGA 
vendors and I think you will get an error saying that you have to pick 
an edge - the FFs in all FPGAs I know of do not work with both edges, 
even the DDR IOBs are implemented with two register banks clocked on 
opposite edges.

It might work the way you intended in simulation but I am almost 100% 
certain that it will fail in synthesis.

>> because counting starts at 0 and you compare with 10, there are actually
>> 11 counts between toggles instead of 10.
> 
> Correct, I need to count to 9.

Article: 113598
Subject: ERROR:MDT - ERROR FROM TCL:- linux_mvl31 ()
From: "Thang Nguyen" <airthang@yahoo.com>
Date: Sun, 17 Dec 2006 21:26:29 -0800
Links: << >>  << T >>  << A >>
Hi,

I start to work on FPGA Embedded system. I am trying to port the MonstaVista Linux on the system.

First I built the system with EDK, the option for my system is: XUPV2P:

powerPC 405 300MHz Bus 100MHz

RS232_Uart_1 OPB UART 1655 (interrupt)

Ethernet_MAC OPB ETHERNET (interrupt)

SysACE_Compact Flash (interrupt) DDR_512MB

I continue to work on software platform which is:

Linux_mv131 version 1.01.b

MEM_SIZE 0x10000000

PLB_CLOCK_FREQ_HZ 100000000 (100 MHz)

Connected_periphs RS232_Uart_1, Ethernet_MAC, SysACE_CompactFlash, opb_intc_0

After generate the bitstream, then Generate Libraries and BSPs, I meet this error:

TARGET_DIR : D:\My_Researches\Workspace\Report2\os\

ERROR:MDT - ERROR FROM TCL:- linux_mvl31 () - /usr/bin/bash: -c: line 1: unexpected EOF while looking for matching `"' /usr/bin/bash: -c: line 2: syntax error: unexpected end of file while executing "exec bash -c "cp -Rfp $cur_dir/linux/* $value"" (procedure "::sw_linux_mvl31_v1_01_b::post_generate" line 166) invoked from within "::sw_linux_mvl31_v1_01_b::post_generate 43482512"

ERROR:MDT - Error while running "post_generate" for processor ppc405_0...

make: *** [ppc405_0/lib/libxil.a] Error 2

If you meet this before, PLease give me some recommendation.

I highly appreciate your help.

Happy Christmas,

Thang Nguyen

Article: 113599
Subject: Re: Xilins ISE Re-Creating Projects
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 18 Dec 2006 07:42:55 +0100
Links: << >>  << T >>  << A >>
"johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag 
news:1166412207.061866.73720@f1g2000cwa.googlegroups.com...
>I believe the original files were ASCII.   The new binary .ise format
> is an "improvement".  I think this was a huge mistake, the project
> file should be text - easily archived, documented, modified, etc.  The
> binary file =is a nightmare for users.
>
> John Providenza
>
AGREE. nightmare, costs time(=money) for almost ever Xilinx PFGA user!

most everyone agree.
Still, Xilinx made the Choice to not use ascii project files :(
possible some lousy programmer told they have too

Antti 





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