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 134450

Article: 134450
Subject: spartan sa dcm maximal frequency
From: Zorjak <Zorjak@gmail.com>
Date: Mon, 11 Aug 2008 07:48:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello

I have few question and if anyone could help me I would be verry
greatfull.


This is a situation. I have 300MHz signal that I have to drive to the
FPGA clock input. That signal I have to connect to the DCM input and
from it to generate new 300MHz clock. But what seems to be a problem.
It turns out that when I generate DCM from the core generator it's
input frequency can't be higher than 250Mhz.

Is it possible to do something like this? Divide the input clock
singal by 2 and the signal that is get connect to the input of the
DCM. And from DCM take the clock that frequency is multiplied by 2.

But how to make this? I doub't that I could easely use T-flip-flop.
How I chould know that output from T-flip-flop is going to use clock
nets. Is the input of DCM always connected to the clock nets so If my
synthesis and implementation pass I would know that idea and design
are ok? is there any problem that could ocure with this approach?

Thanks anyone who read all this untill the end.:)
Like I said, I am greatfull for any kind of help.

Best regards
Zoran

Article: 134451
Subject: Re: spartan sa dcm maximal frequency
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 11 Aug 2008 08:42:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 11, 7:48=A0am, Zorjak <Zor...@gmail.com> wrote:
> Hello
>
> I have few question and if anyone could help me I would be verry
> greatfull.
>
> This is a situation. I have 300MHz signal that I have to drive to the
> FPGA clock input. That signal I have to connect to the DCM input and
> from it to generate new 300MHz clock. But what seems to be a problem.
> It turns out that when I generate DCM from the core generator it's
> input frequency can't be higher than 250Mhz.
>
> Is it possible to do something like this? Divide the input clock
> singal by 2 and the signal that is get connect to the input of the
> DCM. And from DCM take the clock that frequency is multiplied by 2.
>
> But how to make this? I doub't that I could easely use T-flip-flop.
> How I chould know that output from T-flip-flop is going to use clock
> nets. Is the input of DCM always connected to the clock nets so If my
> synthesis and implementation pass I would know that idea and design
> are ok? is there any problem that could ocure with this approach?
>
> Thanks anyone who read all this untill the end.:)
> Like I said, I am greatfull for any kind of help.
>
> Best regards
> Zoran

Look at the Libraries Guide for your Xilinx device family.

In that guide, the parameters for the DCM are explained, including the
precise thing you need:

Attribute: CLKIN_DIVIDE_BY_2
Type: BOOLEAN
Allowed Values: FALSE, TRUE
Default: FALSE
Description: Enables CLKIN divide by two features.

This input divider is in place to take care of this specific problem:
generating clocks from something a little too high speed.  Since the
reference clock will become 150MHz after the divider, you just have to
double back up.

No external logic is needed.

Article: 134452
Subject: Re: Block Rams
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 11 Aug 2008 08:44:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 11, 7:29=A0am, Peter Alfke <al...@sbcglobal.net> wrote:
> On Aug 11, 1:38=A0am, Zhane <m...@hotmail.com> wrote:
>
> > can I read from the FIFO and write into it at the same time? when my 2
> > clocks are independent
>
> Of course you can read and write simultaneously. That's what a FIFO is
> there for. Have you ever read any FIFO description?
> Peter Alfke

Where else can one get information directly from a bona-fide expert on
FIFOs?
Thanks again for being here, Peter.

Article: 134453
Subject: Re: spartan sa dcm maximal frequency
From: austin <austin@xilinx.com>
Date: Mon, 11 Aug 2008 09:23:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 11, 8:42=A0am, John_H <newsgr...@johnhandwork.com> wrote:
> On Aug 11, 7:48=A0am, Zorjak <Zor...@gmail.com> wrote:
>
>
>
> > Hello
>
> > I have few question and if anyone could help me I would be verry
> > greatfull.
>
> > This is a situation. I have 300MHz signal that I have to drive to the
> > FPGA clock input. That signal I have to connect to the DCM input and
> > from it to generate new 300MHz clock. But what seems to be a problem.
> > It turns out that when I generate DCM from the core generator it's
> > input frequency can't be higher than 250Mhz.
>
> > Is it possible to do something like this? Divide the input clock
> > singal by 2 and the signal that is get connect to the input of the
> > DCM. And from DCM take the clock that frequency is multiplied by 2.
>
> > But how to make this? I doub't that I could easely use T-flip-flop.
> > How I chould know that output from T-flip-flop is going to use clock
> > nets. Is the input of DCM always connected to the clock nets so If my
> > synthesis and implementation pass I would know that idea and design
> > are ok? is there any problem that could ocure with this approach?
>
> > Thanks anyone who read all this untill the end.:)
> > Like I said, I am greatfull for any kind of help.
>
> > Best regards
> > Zoran
>
> Look at the Libraries Guide for your Xilinx device family.
>
> In that guide, the parameters for the DCM are explained, including the
> precise thing you need:
>
> Attribute: CLKIN_DIVIDE_BY_2
> Type: BOOLEAN
> Allowed Values: FALSE, TRUE
> Default: FALSE
> Description: Enables CLKIN divide by two features.
>
> This input divider is in place to take care of this specific problem:
> generating clocks from something a little too high speed. =A0Since the
> reference clock will become 150MHz after the divider, you just have to
> double back up.
>
> No external logic is needed.

The CLKFX2X Output (the doubled output) is what you need to use with a
150 MHz input provided by the internal divide by 2 (3A, check specs
for other Spartan 3 product if this is not a 3A).

The Doubled output goes to 300 MHz, even though the input limit is 250
MHz.

Austin

Article: 134454
Subject: Re: Altera question - MAX3000 vs MAX7000
From: jacko <jackokring@gmail.com>
Date: Mon, 11 Aug 2008 09:58:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 11 Aug, 09:52, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> MarkAren wrote:
> > Hi All,
>
> > I have a project that requires a small PLD and have honed in on the
> > Altera series.
>
> > Can someone explain the difference between the EPM7064x and the
> > EPM3064x series please.
>
> > Each shares: same number of CLBs, Icc and Fmax, JTAG.
>
> > The 7k seems newer, but also about twice the price of the 3k
> > (Digikey).
>
> This was a strange exersise in marketing. IIRC
>
> The 3000 series was a lower cost target, but just very slightly crippled
> from the 7000 series. (ie not quite pin compatible. WHY do that?!)
>
> I think the 3000 series offers less IO on given device.
>
> I see the 7000 series has lost link-preference on the Altera website.
>
> These days, Altera's CPLDs are somewhat trailing edge, with Lattice
> 4000ZE being the newest technology (most recently released), followed by
> Atmel's ATF15xxBE, and then Xilinx XC2Cxx series.
>
> Speaking of Altera and CPLD's - whatever became of the touted
> Altera MAX III CPLDs ?
>
> Google finds a 2004 Altera road map that says :
> MAX III CPLDs
> - Intent: Solve Additional Board Management Issues
> - Adjust Density, Power & Cost According to Market Requirements
>
> Seems the plug was pulled on this ?
>
> -jg


wierd? additional board management issues? A reduction would be in
order. 128KB of self refresh single port dram would be nice, at one
less chip (and no pin out change!) or 16*16K*16 bit (256KB). A bit
more denity? Na only the memory (maybe more UFM) or RAM backed UFM (No
extra logic 16 bit parallel, good for conserving design flow).

MORE density LOWER power LOWER cost :-)

How about ? MAX II looks like it was the right dev kit. Maybe memory
should have been integrated UFM RAM MIX,
1270 is quite a lot of LEs.

Article: 134455
Subject: Re: spartan sa dcm maximal frequency
From: Mike Treseler <mtreseler@gmail.com>
Date: Mon, 11 Aug 2008 10:40:50 -0700
Links: << >>  << T >>  << A >>
Zorjak wrote:

> I have 300MHz signal that I have to drive to the
> FPGA clock input. That signal I have to connect to the DCM input and
> from it to generate new 300MHz clock.

If your 300MHz signal can drive an input reliably,
why not make that the clock?

          -- Mike Treseler

Article: 134456
Subject: Re: Downsizing Verilog synthesization.
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 11 Aug 2008 10:49:41 -0800
Links: << >>  << T >>  << A >>
Jim Granville wrote:
(snip, I wrote)

>> Putting analog PLL frequency multipliers on each string would be
>> interesting, but take a lot of extra circuitry.  I don't know
>> DLL enough to say, but it might work.  I would read up on
>> DLL (that is, the digital version of the analog PLL).

> Why add more jitter/noise ? In my example, a low 1Mhz timebase
> reciprocal counter is 63 TIMES more accurate than the OP's
> 15.9mHz spec - so it has 6 extra bits of precision.
> (500KHz would be my trade-off target)

Yes, I was thinking about running it continuously,
or at least close.

> On a more practical note, I can't see a stored-cal approach
> working very well (too much thermal drifing about..)

I agree.

-- glen


Article: 134457
Subject: Re: Downsizing Verilog synthesization.
From: eromlignod <eromlignod@aol.com>
Date: Mon, 11 Aug 2008 12:28:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 11, 1:49=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Yes, I was thinking about running it continuously,
> or at least close.
>
> > On a more practical note, I can't see a stored-cal approach
> > working very well (too much thermal drifing about..)
>
> I agree.
>
> -- glen


Making the tuning accuracy too fine is a waste of time.  I have found
that a string naturally fluctuates in pitch by up to a tenth of a cent
or more, even if it is being resonantly sustained.

I have also let a string be maintained at a constant PWM for up to
three days with no measurable change in pitch.  Maintaining the string
at a constant temperature is basically the same as an ordinary piano
sitting at room temperature.  Gradual changes in humidity are by far
the largest factor in causing a piano to go out of tune anyway.

Don
Kansas City

Article: 134458
Subject: Re: Downsizing Verilog synthesization.
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 12 Aug 2008 09:27:53 +1200
Links: << >>  << T >>  << A >>
eromlignod wrote:
> On Aug 11, 1:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> 
>>Yes, I was thinking about running it continuously,
>>or at least close.
>>
>>
>>>On a more practical note, I can't see a stored-cal approach
>>>working very well (too much thermal drifing about..)
>>
>>I agree.
>>
>>-- glen
> 
> Making the tuning accuracy too fine is a waste of time. 

Not to an engineer ;)

> I have found
> that a string naturally fluctuates in pitch by up to a tenth of a cent
> or more, even if it is being resonantly sustained.

but how do you know if that variation is the resonance changing, or your 
measurement noise floor ?

<paste>
 > I need an accuracy of
 > less than one "cent" (1/100th of a musical semitone).  One cent sharp
 > at 27.5 Hz is
 > 27.5 * (2**(1/1200)) = 27.5159 Hz

So that's ~477ppm, and the one tenth you mention is 47ppm - and that has 
to be close to the noise floor of sense of a single note (14+ bits),
(expect rather worse measurement floor on 44 notes all at once!)


> I have also let a string be maintained at a constant PWM for up to
> three days with no measurable change in pitch.  Maintaining the string
> at a constant temperature is basically the same as an ordinary piano
> sitting at room temperature. 

Almost : It depends on your total power budget, needed for your thermal 
expansion tuning. All that 'abnormal' heat is going to spread slowly, 
and also dry things out - so you will have a lot of time constants
in a working system.

How many watts does this typically drain, when running ?

Coefficent of thermal expansion of the range of strings ?
(steel is ~11-13ppm/'C)

-jg


Article: 134459
Subject: Optimizing a LUT-based pow(val, 2.2)
From: Ben Jackson <ben@ben.com>
Date: Mon, 11 Aug 2008 22:07:39 GMT
Links: << >>  << T >>  << A >>
I'm taking gamma-corrected RGB and displaying it on a linear device.  If
you consider R, G, B in [0,1) then R' = R ** 2.2 and so on.  For my first
version I just instantiated an 8-bit 'square' megafunction in Quartus,
which turns out to be 30 LUTs (possibly less at map time because I'm
ignoring the lower 8 bits of the output).  Obviously the power of 2 isn't
quite a power of 2.2.  After testing a RAM-based lookup table to do 2.2,
I decided to build the equivalent case statement and see how it worked
out.  119 LUTs.

The table has many repeated value at the low end and skips some values at
the high end.  The transition points between runs of values (at the low
end) and the exact values (at the high end) could be shifted "slightly"
with little quality penalty but possibly space savings.  Is there a
methodical way to minimize the logic by allowing these slight errors?  I
can't just 'x' some values because I care about monotonicity.

(and yes, I'm aware that my internal color path should probably be wider
than my output 8 bits, at which point this may become moot, but I'm still
curious)

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 134460
Subject: Re: Downsizing Verilog synthesization.
From: eromlignod <eromlignod@aol.com>
Date: Mon, 11 Aug 2008 15:10:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 11, 4:27=A0pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> > Making the tuning accuracy too fine is a waste of time.
>
> Not to an engineer ;)


I am an engineer with 22 years' experience (UMR 1986).  I also studied
piano at the UMKC Consevatory of Music for sixteen years, starting in
1972.



> > I have found
> > that a string naturally fluctuates in pitch by up to a tenth of a cent
> > or more, even if it is being resonantly sustained.
>
> but how do you know if that variation is the resonance changing, or your
> measurement noise floor ?


Believe me, I have extensively researched pitch and tuning, with help
from the Piano Technicians Guild (of which I am a member) and the ME
department of the University of Wichita.  Counting a 50 MHz clock
gives me much more accuracy than is needed.


> So that's ~477ppm, and the one tenth you mention is 47ppm - and that has
> to be close to the noise floor of sense of a single note (14+ bits),
> (expect rather worse measurement floor on 44 notes all at once!)
>
> > I have also let a string be maintained at a constant PWM for up to
> > three days with no measurable change in pitch. =A0Maintaining the strin=
g
> > at a constant temperature is basically the same as an ordinary piano
> > sitting at room temperature.
>
> Almost : It depends on your total power budget, needed for your thermal
> expansion tuning. All that 'abnormal' heat is going to spread slowly,
> and also dry things out - so you will have a lot of time constants
> in a working system.
>
> How many watts does this typically drain, when running ?


Power consumption is a function of tuning range and how far each
string is out of tune.  A study was done at the University of
Washington where it was proven that a piano varies in pitch cyclically
by less than 20 cents (total runout, worst string) throughout each
year (it was a 3-1/2-year study).  So I am aiming at a tuning range of
about 30 cents to start out with.  This would take about 750 watts if
every single string were the entire 30 cents out of tune (sharp).

Don
Kansas City

Article: 134461
Subject: Re: Block Rams
From: Zhane <me75@hotmail.com>
Date: Mon, 11 Aug 2008 17:04:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 11, 10:29=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
> On Aug 11, 1:38=A0am, Zhane <m...@hotmail.com> wrote:
>
> > can I read from the FIFO and write into it at the same time? when my 2
> > clocks are independent
>
> Of course you can read and write simultaneously. That's what a FIFO is
> there for. Have you ever read any FIFO description?
> Peter Alfke

I was just wondering...
cause I still dont know why I met with fifo_full active when it isnt

Article: 134462
Subject: Re: Optimizing a LUT-based pow(val, 2.2)
From: "KJ" <kkjennings@sbcglobal.net>
Date: Mon, 11 Aug 2008 20:07:23 -0400
Links: << >>  << T >>  << A >>

"Ben Jackson" <ben@ben.com> wrote in message 
news:slrnga1e1b.1ep2.ben@saturn.home.ben.com...
> I'm taking gamma-corrected RGB and displaying it on a linear device.  If
> you consider R, G, B in [0,1) then R' = R ** 2.2 and so on.  For my first
> version I just instantiated an 8-bit 'square' megafunction in Quartus,
> which turns out to be 30 LUTs (possibly less at map time because I'm
> ignoring the lower 8 bits of the output).  Obviously the power of 2 isn't
> quite a power of 2.2.

Odd why it should take any LUTs at all...or are you targetting something 
that doesn't have hardware multipliers?

> After testing a RAM-based lookup table to do 2.2,
> I decided to build the equivalent case statement and see how it worked
> out.  119 LUTs.
>

Doesn't sound like a lookup table got implemented using internal device 
memory...or are you targetting something that doesn't have internal memory?

Let's see, no hardware multipliers, no internal memory...my god man, what 
are you using, self-assembling carbon nanotube based logic?

> The table has many repeated value at the low end and skips some values at
> the high end.  The transition points between runs of values (at the low
> end) and the exact values (at the high end) could be shifted "slightly"
> with little quality penalty but possibly space savings.  Is there a
> methodical way to minimize the logic by allowing these slight errors?  I
> can't just 'x' some values because I care about monotonicity.
>
> (and yes, I'm aware that my internal color path should probably be wider
> than my output 8 bits, at which point this may become moot, but I'm still
> curious)
>

See the link below for how I did an sRGB->RGB conversion function.  Cleaner 
and easier to validate than a case statement.

http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/b2e4be6480069641/e0ef01b07a9c39cd?hl=en&lnk=st&q=RGB+sRGB+conversion+function+Kevin+Jennings#e0ef01b07a9c39cd

Once you've got the constants computed, don't forget to put it into a 
synchronous process otherwise it will get implemented in LUTs rather than 
internal memory.  I'm guessing that's what happened with your case statement 
lookup table.

i.e. Gazouta <= Lookup(Gazinta) when rising_edge(Clock);

Kevin Jennings 



Article: 134463
Subject: Re: Block Rams
From: Peter Alfke <alfke@sbcglobal.net>
Date: Mon, 11 Aug 2008 20:32:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 11, 8:44=A0am, John_H <newsgr...@johnhandwork.com> wrote:
> On Aug 11, 7:29=A0am, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > On Aug 11, 1:38=A0am, Zhane <m...@hotmail.com> wrote:
>
> > > can I read from the FIFO and write into it at the same time? when my =
2
> > > clocks are independent
>
> > Of course you can read and write simultaneously. That's what a FIFO is
> > there for. Have you ever read any FIFO description?
> > Peter Alfke
>
> Where else can one get information directly from a bona-fide expert on
> FIFOs?
> Thanks again for being here, Peter.


Article: 134464
Subject: Re: Block Rams
From: Peter Alfke <alfke@sbcglobal.net>
Date: Mon, 11 Aug 2008 20:36:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 11, 8:44=A0am, John_H <newsgr...@johnhandwork.com> wrote:

> Where else can one get information directly from a bona-fide expert on
> FIFOs?
> Thanks again for being here, Peter.

Hi, John.
Is this what you had in mind?

FIFOs, a tutorial description by Peter Alfke   8-11-2008
A FIFO is a sequential data buffer that is very easy to use:
Write a sequence of data words into the FIFO, and read them out in the
same sequence. Writing and reading can overlap. There is no explicit
addressing.
Most practical implementations use a dual-ported memory (RAM), writing
into one port, addressed by the write counter, and reading through the
other port, addressed by the read counter. This allows the use of two
totally independent clocks for write and read. This is often called
asynchronous operation, although writing as well as reading are each
synchronous operation in their respective clock domain.

Most FIFO designs require free-running clocks, where the write or read
operation is controlled by the respective clock enable. A typical FIFO
has a DATA IN bus, a DATA OUT bus, a free-running write clock with its
Enable control, and a free-running read clock with its Enable control.
Such a FIFO is very easy to use, since it hides all functional and
timing complexity from the user.

FLAGS:
The FIFO uses an EMPTY flag to signal to the user that no more read
operations should be started. At other times the FULL flag can tells
the user that no more write operation should be started.
Generating these flags requires that the two addressing counters be
compared for equality (identity), although they are incremented by two
independent clocks. This is a very tricky operation. To avoid
uncontrolled asynchronous decoding spikes, the counters usually count
in a Gray sequence, where only one bit changes on any increment.
And the two clocks can interact and might cause metastable delays.
Even more complex is the decoding of Almost Empty and Almost Full
conditions, especially when their offset values are programmable.
The user is isolated from all these complexities, but must accept
certain timing ambiguities. The Full and Empty flags will always go
active exactly on-time, to stop further reading or writing, but these
flags must of necessity be allowed to take several clock periods to go
inactive again.
When the first word is being written into an empty FIFO, Empty goes
low, and waits for an enabled read clock to present the Data on the
DATA OUT bus.
There is a special mode of operation, called First Word Fall Through
(FWFT), where the first word written into the empty FIFO directly, on
its own, appears at the DATA OUT port.
The conventional mode can be called Pull, while FWFT can be called
Push. The two modes differ only in their response to the first write
into an empty FIFO.
The preceding described the most demanding case of a high-speed dual-
clock (asynchronous) FIFO. In the special case where both clocks are
identical (even if individually enabled) the internal decoding is much
simpler, and the binary counters and the control can be designed like
a synchronous state machine.
At low clock rates, the two clocks can be synchronized to each other,
or the read and write operations can be time-multiplexed in a single-
port memory.
Very small FIFOs can be implemented with flip-flops or register
arrays, sometimes even with shift registers.



Article: 134465
Subject: Re: spartan sa dcm maximal frequency
From: Zorjak <Zorjak@gmail.com>
Date: Mon, 11 Aug 2008 22:39:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
thanks to everyone
you help me a lot.

I didn't know about this clk_divide_by_2 attribute. I tryed it and I
got what I've needed. That was solution.

one more time thanks a lot.

best regards
Zoran

On Aug 11, 7:40=A0pm, Mike Treseler <mtrese...@gmail.com> wrote:
> Zorjak wrote:
> > I have 300MHz signal that I have to drive to the
> > FPGA clock input. That signal I have to connect to the DCM input and
> > from it to generate new 300MHz clock.
>
> If your 300MHz signal can drive an input reliably,
> why not make that the clock?
>
> =A0 =A0 =A0 =A0 =A0 -- Mike Treseler


Article: 134466
Subject: Re: Development board with SD card.
From: Antti <Antti.Lukats@googlemail.com>
Date: Mon, 11 Aug 2008 22:56:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 8 aug, 23:59, John McCaskill <jhmccask...@gmail.com> wrote:
> On Aug 8, 3:09=A0pm, "Pete Fraser" <pfra...@covad.net> wrote:
>
> > I'm looking for an FPGA (any flavor) development board
> > with an SD card socket connected to the FPGA.
>
> > It must have all the pins connected (not just SPI mode).
>
> > So FAR I've found the Arrow LPRP.
> > Any other suggestions?
>
> > Thanks
>
> > Pete
>
> A project that Antti did is almost what you want:http://www.microdream-1.=
com/Pmod-B.html
>
> It has SD connected, but only in one bit mode.
>
> When we developed out cards we put a miniSD card slot on the back of
> them:
>
> http://www.fastertechnology.com/extras/pics/p6a/p6a_back_tn.jpg
>
> For our development, we just soldered a miniSD to SD converter to a
> ribbon cable that was crimped to a DIN connector. Then we plugged that
> into an Avnet development board. =A0We put a few caps on the power pins,
> and series terminated at the miniSD converter. That worked like a
> charm, and it was quick and easy as long as you have the stuff to
> solder with. The miniSD to SD converter came with the miniSD card.
>
> We use the miniSD to configure the V4FX, then it boots its software
> from it. We use it in both SD and SPI modes.
>
> Regards,
>
> John McCaskillwww.FasterTechnology.com

Hi John,

I am glad that it has not been left un-noticed, as per distribution
agreement the product is now also available from german development
board distributor
http://shop.trenz-electronic.de/catalog/product_info.php?cPath=3D66&product=
s_id=3D348

I believe all Xilinx development boards with the 6 pin connector sold
by Trenz are bundled with the micro-SD board without extra surchage to
the price.

This reminds me that I have not published yet all my supporting
libraries and _IP_cores_ and reference designs that I have developed
for SD and microblaze. I still intend todo that, just my days still
have only 25 hours ;)

Besides that I am developing more FPGA products and accessories,
hopefully rolling our first products in september already

Antti

PS there are some SD mode ip cores out in the wild.. not very rigid
though







Article: 134467
Subject: SDIO open source code
From: Pinhas <bknpk@hotmail.com>
Date: Tue, 12 Aug 2008 00:27:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi
I need help in completeing an SDIO open source code.

http://bknpk.no-ip.biz/SDIO/doc_1.html
http://bknpk.no-ip.biz/

Article: 134468
Subject: Re: Block Rams
From: Jahid <alicahitkosger@gmail.com>
Date: Tue, 12 Aug 2008 01:20:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
i couldn't catch one point: suppose we are to write 4 data each
weighting one byte on fifo. when we enable writing on fifo for
example, how should we send in the data? when it takes the data and
stores: at rising edges of clock? or at rising edges of enable signal?
what happens if i enable writing all the time and do not change the
data im sending in? will it keep writing the same data until it is
full?

thanks..

Article: 134469
Subject: Re: Development board with SD card.
From: John Adair <g1@enterpoint.co.uk>
Date: Tue, 12 Aug 2008 03:16:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
Pete

We have a a SDCARD module to go with our Raggedstone1, Broaddown2/4
and Mulldonoch products. It supports all the pins and has a mosfet
power switch to allow crude resets. I don't believe it''s listed on
our shop or general websites yet but it is in stock and available. We
have some updates for the website ongoing and I think these will
appear early September with all the new products etc..

Links for the above boards:

http://www.enterpoint.co.uk/moelbryn/raggedstone1.html

http://www.enterpoint.co.uk/moelbryn/broaddown2.html

John Adair
Enterpoint Ltd.


On Aug 8, 9:09=A0pm, "Pete Fraser" <pfra...@covad.net> wrote:
> I'm looking for an FPGA (any flavor) development board
> with an SD card socket connected to the FPGA.
>
> It must have all the pins connected (not just SPI mode).
>
> So FAR I've found the Arrow LPRP.
> Any other suggestions?
>
> Thanks
>
> Pete


Article: 134470
Subject: Re: SDIO open source code
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 12 Aug 2008 03:19:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 12 aug, 10:27, Pinhas <bk...@hotmail.com> wrote:
> Hi
> I need help in completeing an SDIO open source code.
>
> http://bknpk.no-ip.biz/SDIO/doc_1.htmlhttp://bknpk.no-ip.biz/

what help do you want, need or expect?

the SDIO specs are all under NDA and there are also no known
opensource SDIO software drivers where to "derive" missing
information.

Antti

From glaser@ict.tuwien.ac.at Tue Aug 12 03:40:45 2008
Path: nlpi059.nbdc.sbc.com!nlpi062.nbdc.sbc.com!prodigy.com!nlpi057.nbdc.sbc.com!prodigy.net!feeder.erje.net!newsfeed.utanet.at!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail
Newsgroups: comp.arch.fpga
Subject: Re: RTL Schematic as EDIF
From: Johann Glaser <glaser@ict.tuwien.ac.at>
In-Reply-To: <3n9o94ps5t0t8oiarac6f0im9g4p91cf7u@4ax.com>
References: <1218101383.15335.13.camel@glaser>
	 <kmql9456jj9kt53rm5qo7g371rn65daaqp@4ax.com>
	 <1218113983.15335.25.camel@glaser>
	 <3n9o94ps5t0t8oiarac6f0im9g4p91cf7u@4ax.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1218537644.16588.17.camel@glaser>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Date: Tue, 12 Aug 2008 12:40:45 +0200
Lines: 27
NNTP-Posting-Host: pc53.ict.tuwien.ac.at
X-Trace: 1218537510 tunews.univie.ac.at 28520 128.131.80.53
X-Complaints-To: abuse@tuwien.ac.at
Xref: prodigy.net comp.arch.fpga:147247
X-Received-Date: Tue, 12 Aug 2008 06:39:21 EDT (nlpi059.nbdc.sbc.com)

Hi!

> >The HDL netlist is quite nice for me, but unfortunately a bit hard to
> >work with. I'd have to implement a complex parser and as well as some
> >"small synthesis" algorithms.
> 
> I question how complex the parser would need to be; it only needs to
> understand a small subset of full VHDL. Alternatively, there are VHDL
> parsers you could possibly use as a starting point, thought I suspect a
> simple recursive descent parser would be faster to write than
> researching them.

You are right. The output of RTL Compiler (a Verilog netlist) is indeed
very simple structured code, structural code. It instantiates wires,
gates (nand, not, xor, ...), modules and special Cadence-modules
(CDN_mux2, CDN_flop, ...).

I found that Icarus Verilog can translate this to EDIF nicely.
unfortunately its a flat netlist, but besides that, it looks like I
found what I was searching for. And if its not ok, I found a
Verilog-parser from the IWLS benchmarks. Probably this can be used to
transform Verilog to EDIF.

Thanks for your hints
  Hansi



Article: 134471
Subject: Re: RTL Schematic as EDIF
From: Johann Glaser <glaser@ict.tuwien.ac.at>
Date: Tue, 12 Aug 2008 12:41:49 +0200
Links: << >>  << T >>  << A >>
Hi Glen!

> I think you can just restrict what you allow.  There is much
> that could be written in verilog that current synthesis tools
> won't allow.  (FF's that work on both edges of the clock,
> as an example.)   I would say that you should allow all
> forms of wiring, but restrict what can be connected to
> those wires.

Thanks. Please see my post to Brian Drummond.

Bye
  Hansi



From glaser@ict.tuwien.ac.at Tue Aug 12 04:43:38 2008
Path: nlpi059.nbdc.sbc.com!nlpi062.nbdc.sbc.com!prodigy.com!nlpi057.nbdc.sbc.com!prodigy.net!newsfeed-00.mathworks.com!kanaga.switch.ch!switch.ch!newsserver.news.garr.it!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail
Newsgroups: comp.arch.fpga
Subject: Re: RTL Schematic as EDIF
From: Johann Glaser <glaser@ict.tuwien.ac.at>
In-Reply-To: <489C5F10.70600@gmail.com>
References: <1218101383.15335.13.camel@glaser>
	 <kmql9456jj9kt53rm5qo7g371rn65daaqp@4ax.com>
	 <1218113983.15335.25.camel@glaser>  <489B1687.4020203@gmail.com>
	 <1218185634.15335.41.camel@glaser>  <489C5F10.70600@gmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1218541418.16588.30.camel@glaser>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Date: Tue, 12 Aug 2008 13:43:38 +0200
Lines: 69
NNTP-Posting-Host: pc53.ict.tuwien.ac.at
X-Trace: 1218541283 tunews.univie.ac.at 28520 128.131.80.53
X-Complaints-To: abuse@tuwien.ac.at
Xref: prodigy.net comp.arch.fpga:147249
X-Received-Date: Tue, 12 Aug 2008 07:44:42 EDT (nlpi059.nbdc.sbc.com)

Hi!

> > Some background information to make my intent plausible: In my PhD I'm
> > investigating how to build custom ultra-low-power logic to a SoC, which
> > is still configurable.
> 
> By 'build' do you mean layout a custom chip
> with special primitive logic elements
> and electronic wiring,
> or do you mean make a bit image for
> existing or proposed fpga hardware?

My proposal as PhD is to develop one's own tailored FPGA to be put to a
SoC. Therefore my proposal includes
 1) define which logic elements and routing resources and configuration
    possibilities you need
 2) introduce configuration facility
 3) technology map, place&route, layout, chip fabrication
 4) utilize the reconfigurable circuit to implement the desired function
 5) generate a bitstream for it

Very short, very imprecise, and very demanding. To reduce my work I plan
to utilize commercial and academic tools for the individual steps. And
my original question was regarding one of the steps.

> > On a continuum of configurability between
> > fine-grained (e.g. FPGA, CPLD) to coarse-grained (e.g. Cypress PSoC) my
> > plan is to stay in between. Therefore the RTL netlist, i.e. the first
> > synthesis step, is near my planned granularity.
> 
> This is where you lose me.
> Granularity of what?
> The logical source text,
> some intermediate logical description,
> or the hardware container that holds the compiled bit image?

The granularity of logic blocks and their configurability. FPGAs allow
to configure every single bit, but also require you to do. To reduce the
chip area and delay the implement high-level functions like multipliers,
block rams, even whole CPUs. I plan to use larger logic blocks with less
arbitrary function, e.g. adders, counters, multi-bit wide logic blocks,
multiplexers, ...

> > VHDL or Verilog are too user-dependent and flexible.
> 
> Only if a human creates the code.
> 
> A quartus .vho file is machine generated netlist
> of primitive elements that just happens to use
> structural vhdl as a *netlist* format.
> As others have said, this could be translated to edif.

Please see my reply to Brian Drummond for what I've found out in the
meantime.

> Now, if *you* want to specify which logical elements
> synthesis is to use, tools from A and X won't help.
> In that case, you need a library generation package
> from one of the major synthesis vendors.
> Then you can make any kind of netlist you like,
> but you are on your own for simulation or a target device.

I found that the RTL Compiler accepts "Liberty" library description
files. Hopefully I can utilize these for my work.

Bye
  Hansi



Article: 134472
Subject: Re: Block Rams
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 12 Aug 2008 06:06:44 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> On Aug 11, 8:44 am, John_H <newsgr...@johnhandwork.com> wrote:
> 
>> Where else can one get information directly from a bona-fide expert on
>> FIFOs?
>> Thanks again for being here, Peter.
> 
> Hi, John.
> Is this what you had in mind?
<snip>

All I had in mind, honestly, was thanks.

Article: 134473
Subject: Re: Block Rams
From: Peter Alfke <alfke@sbcglobal.net>
Date: Tue, 12 Aug 2008 07:20:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 12, 1:20=A0am, Jahid <alicahitkos...@gmail.com> wrote:
> i couldn't catch one point: suppose we are to write 4 data each
> weighting one byte on fifo. when we enable writing on fifo for
> example, how should we send in the data? when it takes the data and
> stores: at rising edges of clock? or at rising edges of enable signal?
> what happens if i enable writing all the time and do not change the
> data im sending in? will it keep writing the same data until it is
> full?
>
> thanks..

The answer to your questions is: Yes.
Think of the write port as a simple register. It writes data on the
rising clock edge (sometimes the edge polarity is programmable)
provided the Enable is active at that moment. If you tell it to write
the same data multiple times, it will do that, just like any dumb
register would do.
Peter Alfke

Article: 134474
Subject: [Xilinx]:SetClbBits() function in HWICAP
From: hooshaya@gmail.com
Date: Tue, 12 Aug 2008 09:46:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
Has anyone successfully used SetClbBits() function of HWICAP 1.00a
(driver 2.01a) in EDK 10.1 on Virtex-5?
I am getting the impression that it doesn't work at all!

Cheers,




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