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 125950

Article: 125950
Subject: Re: ROM (altsyncram) corruption
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 09 Nov 2007 16:38:34 -0800
Links: << >>  << T >>  << A >>
On Nov 9, 2:37 pm, "Symon" <symon_bre...@hotmail.com> wrote:
> >
> FYI, some of Xilinx's RAMs have a similar (maybe the same?) problem.http://www.xilinx.com/support/answers/21870.htm
> HTH., Syms.

This is correct,and we document it also, after having detected this
accidentally.

If the RAM is selected, even if WE is inactive, a violation of the
address set-up time CAN occasionally corrupt the RAM=ROM content.
This may sound strange.
How can anything write a data corruption when WE is inactive?

If address lines change at a certain place inside the specified set-up
time window, then two different address decoders can be activated
simultaneously, and interconnect different data locations through
their sneak path. Ugly!

It's not very likely, but we have measured it. It is real.

Moral:
Never violate the address timing with repect to the set-up time before
the active clock edge.
If you have to violate it, make sure that the Memory Enable signal is
inactive, not only the Write Enable. Then there will be no problem
whatsoever.

Peter Alfke, Xilinx Applications



Article: 125951
Subject: Re: Xilinx Parallel Cable IV, API spec
From: kgll8ss@yahoo.com
Date: Fri, 09 Nov 2007 16:46:17 -0800
Links: << >>  << T >>  << A >>
> it is SUPER SECRET :(
>
> thats also the reason there are no 3rd party drivers
> thats the reason why it works so bad - on most cases the Cable IV
> works in Cable III fallback mode because of SUPERS**** windriver stuff
> that just failes

The Parallel cable IV DLC7 rev4 uses Xilinx XCR3384XL (384 Macrocell
CPLD, 5V tolerant I/O pins with 3.3V core supply) and 40.000MHz clock.
Which software makes direct use of this cable ..?, trying to figure
out a setup for testing. Such that I can trigger an operation and
measure the resulting action.

The P-IV advantages over a plain parallel port interface is likely
only data integrity and improved speed over plain bit-banging. So it
uses ECP to get fast data transfer and add some data integrity check
like crc. Uses some fifo that directly feed the fpga through jtag or
cclk/d0 interface. In essence:
Parallel ECP -> CRC -> FIFO -> Bitbang

Otoh, It seems almost simpler to put together a CPLD + PHY and some
cables that will do the job without loops & hoops :), but a finished
circuit has some advantages.

Don't forget to bite the hand that buys from you! :-)


Article: 125952
Subject: System ACE generation
From: "ajith.thamara@gmail.com" <ajith.thamara@gmail.com>
Date: Sat, 10 Nov 2007 01:28:47 -0000
Links: << >>  << T >>  << A >>
Hi,
 I am trying to generate system ACE file in EDK 9.1 .  I am trying to
combine bitstream
 with zImage.elf  which is used to boot Monta vist linux in XUP
board.
I am using the following command to generate it.
  "xmd -tcl genace.tcl -opt genace.opt"
I was able to generate it with out any error in EDK 8.1.
Can Any one  suggest some solution?
Thank you,
Ajith


Article: 125953
Subject: SystemACE generation
From: "ajith.thamara@gmail.com" <ajith.thamara@gmail.com>
Date: Sat, 10 Nov 2007 01:34:22 -0000
Links: << >>  << T >>  << A >>
Hi,
I am ajith again.
Sorry I forgot to tell  you about the error message.
The error that I am getting is "Unable to open ELF file, ELF file
might have corrupted."
ajith.


Article: 125954
Subject: Re: ROM (altsyncram) corruption
From: cs_posting@hotmail.com
Date: Fri, 09 Nov 2007 17:59:48 -0800
Links: << >>  << T >>  << A >>
On Nov 9, 7:38 pm, Peter Alfke <pe...@xilinx.com> wrote:

> If the RAM is selected, even if WE is inactive, a violation of the
> address set-up time CAN occasionally corrupt the RAM=ROM content.
> This may sound strange.
> How can anything write a data corruption when WE is inactive?

Yes, that's what had us all scratching our heads today!

> If address lines change at a certain place inside the specified set-up
> time window, then two different address decoders can be activated
> simultaneously, and interconnect different data locations through
> their sneak path. Ugly!
>
> It's not very likely, but we have measured it. It is real.

Aha, now that actually makes sense.  I wonder if the same mechanism is
at fault for the very real behaviour I'm seeing in an Altera part when
I turn the clock source on and off.

I have verified that deactivating the memory's clock enable will
"protect" it from clock irregularities... unfortunately, the memory is
in use nearly full time.

I've received a suggestion to use the PLL for the logic, and use the
lock output to drive the memory enable... will have to try that next
week.  Clock PLL by itself reduced the risk of corruption
substantially, but not to zero.


Article: 125955
Subject: Re: Xilinx Parallel Cable IV, API spec
From: cs_posting@hotmail.com
Date: Fri, 09 Nov 2007 18:29:14 -0800
Links: << >>  << T >>  << A >>
On Nov 9, 7:46 pm, kgll...@yahoo.com wrote:

> The P-IV advantages over a plain parallel port interface is likely
> only data integrity and improved speed over plain bit-banging. So it
> uses ECP to get fast data transfer and add some data integrity check
> like crc. Uses some fifo that directly feed the fpga through jtag or
> cclk/d0 interface. In essence:
> Parallel ECP -> CRC -> FIFO -> Bitbang

I this day and age you might as well use USB, getting you
compatability with your travel laptop, etc...


Article: 125956
Subject: Re: Non-volatile FPGA in a small package
From: cs_posting@hotmail.com
Date: Fri, 09 Nov 2007 18:39:06 -0800
Links: << >>  << T >>  << A >>
On Nov 8, 10:14 am, Kryvor <kris.vorw...@gmail.com> wrote:

> You might find that Actel suits your needs ...
>
> http://www.actel.com/documents/selguide.pdf
>
> (It looks as though Actel carries some smaller ProASICPlus parts in a
> TQFP 100 package.  Those parts have 2 PLLs and are Flash-based
> [reprogrammable, immune to SEUs, etc.].)

Yes, however there's a big differnece between developing for these vs.
Altera or Xilinx SRAM parts: the toolchain is less integrated and thus
much slower, and the programmer is outrageously slow and pricey for
what you get.  If you are used to fully integrated toolflow, and to
doing fast test downloads during development, this can be quite
aggravating.

It also seems that you can't get pullups on inputs, and instead of
merely being cautioned against using non-clock inputs as clocks, you
literally can't do it - meaning board designs with stupid mistakes
that might be programmed away with other devices are more likely to
require modifications with these.

On the other hand, if you prefer to do everything in simulation and
not make incremental trials in hardware, and you value synopsis over X
or A's tools enough to habitually use it anyway, then maybe these
parts are just your thing.


Article: 125957
Subject: Is "Insight IJC-02" and "Xilinx parallel download cable" the same?
From: kgll8ss@yahoo.com
Date: Fri, 09 Nov 2007 20:43:51 -0800
Links: << >>  << T >>  << A >>
When looking at this schematic:
http://www.xilinx.com/support/programr/jtag_cable.pdf

And comparing with the pcb layout of Insight jtag IJC-02 parallel port
dongle. They seem to be the same thing. Is that so .. ?

Any catches with it?, I saw some posts about removing C1 and
unnecessary filtering.
I assume that it's powered from the circuit to be programmed, and thus
using the 74HC125D capability to withstand +5V while powering it from
a lower voltage to make it's outputs compatible with the +2.5V or
+3.3V circuit.

(maybe next project will be Ethernet PHY+CPLD+Jtag :-)


Article: 125958
Subject: Re: FIFO interface design
From: Readon <xydarcher@gmail.com>
Date: Sat, 10 Nov 2007 04:56:54 -0000
Links: << >>  << T >>  << A >>
On Nov 9, 10:54 am, Gabor <ga...@alacron.com> wrote:
> On Nov 8, 8:25 pm, Readon <xydarc...@gmail.com> wrote:
>
>
>
> > On Nov 9, 8:07 am, Dave Pollum <vze24...@verizon.net> wrote:
>
> > > On Nov 8, 8:15 am, Readon <xydarc...@gmail.com> wrote:
>
> > > >    i want to read & write data to/from a fifo placed in fpga.  MCU's
> > > > external bus is connected to the chip. I am using the sync-fifo ip of
> > > > Altera CycloneII. The data bus and control signal are connected to
> > > > fifo directly. it's unfortune that when i read once from bus, data
> > > > would be read twice from fifo because there are two clock rising edges
> > > > during read signal(low active) is resetted. I think it will read more
> > > > datas from fifo if the read signal is resetted long enough.
> > > >    Is there any good design for fifo interface connecting on the
> > > > exteranl bus?
>
> > > Using a Synchronous FIFO implies that the read clock and the write
> > > clock are in the same clock domain.  Is your MCU supplying the FIFO's
> > > clock or is the FPGA supplying the MCU's clock?  If the clock sources
> > > are different, then you either need an Asynchronous FIFO, or you need
> > > to run the MCU and FPGA from the same clock.
> > > HTH
> > > -Dave Pollum
>
> > It is in different clock, i tried altera's asynchronous FIFO which
> > need two extra clock for reading.
> > is there any better solution?
>
> If your MCU is running much slower than the FPGA, you can use the
> FPGA's internal clock to run the synchronous FIFO, and a little
> state logic to generate the necessary (single cycle) pulses for
> read and write from the MCU interface signals.

unfortunately, the problem i met is on the contrary. MCU is much
faster then FPGA, about 4 times.


Article: 125959
Subject: Re: Xilinx Parallel Cable IV, API spec
From: Eric Smith <eric@brouhaha.com>
Date: Fri, 09 Nov 2007 21:59:51 -0800
Links: << >>  << T >>  << A >>
cs_posting@hotmail.com writes:
> I this day and age you might as well use USB, getting you
> compatability with your travel laptop, etc...

However, if you want to write your own code to talk to the standard
firmware of the Xilinx Platform USB Cable (rather than using Impact,
Chipscope, and XMD), you'll probably *still* have to reverse-engineer
the CPLD bits.

Article: 125960
Subject: Re: ROM (altsyncram) corruption
From: Eric Smith <eric@brouhaha.com>
Date: Fri, 09 Nov 2007 22:05:42 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> If the RAM is selected, even if WE is inactive, a violation of the
> address set-up time CAN occasionally corrupt the RAM=ROM content.

Thanks for psting about the problem and the cause.  Is this true of
all Xilinx parts with BRAM?  Is there any plan to "fix" it in future
FPGAs?

Can I assume that the ISE post-P&R static timing analysis will generate
an error if the BRAM address setup time will not be met?  I"m not sure
of the limitations of the static timing analysis, but I've never seen
any such error reported, so maybe my designs are OK.

Eric



Article: 125961
Subject: Re: ROM (altsyncram) corruption
From: Peter Alfke <alfke@sbcglobal.net>
Date: Fri, 09 Nov 2007 22:34:14 -0800
Links: << >>  << T >>  << A >>
On Nov 9, 10:05 pm, Eric Smith <e...@brouhaha.com> wrote:
> Peter Alfke wrote:
> > If the RAM is selected, even if WE is inactive, a violation of the
> > address set-up time CAN occasionally corrupt the RAM=ROM content.
>
> Thanks for psting about the problem and the cause.  Is this true of
> all Xilinx parts with BRAM?  Is there any plan to "fix" it in future
> FPGAs?
>
> Can I assume that the ISE post-P&R static timing analysis will generate
> an error if the BRAM address setup time will not be met?  I"m not sure
> of the limitations of the static timing analysis, but I've never seen
> any such error reported, so maybe my designs are OK.
>
> Eric

The problem is somewhat exotic. Violating address timing with respect
to the clock would obviously always be a disaster when WE is active
(You would write data into weird uncontrolled locations).
Intuitively one might think that this should not be a problem in read
mode, although the data output would of course be garbage.
We had one user with asynchronously free-running address sequences,
but his system ignored the output most of the time. He ws very
surprised when he found the data contaminated. In his case the
solution was trivial: Disable the BRAM whenever possible.
I do not know about atomatic warnings.
A clock is also called a "trigger", and it might be wise to remember
the weapons-derived origin...
Peter Alfke, Xilinx



Article: 125962
Subject: Re: ROM (altsyncram) corruption
From: Peter Alfke <alfke@sbcglobal.net>
Date: Fri, 09 Nov 2007 22:43:51 -0800
Links: << >>  << T >>  << A >>
On Nov 9, 10:34 pm, Peter Alfke <al...@sbcglobal.net> wrote:
> On Nov 9, 10:05 pm, Eric Smith <e...@brouhaha.com> wrote:
>
> > Peter Alfke wrote:
> > > If the RAM is selected, even if WE is inactive, a violation of the
> > > address set-up time CAN occasionally corrupt the RAM=ROM content.
>
> > Thanks for psting about the problem and the cause.  Is this true of
> > all Xilinx parts with BRAM?  Is there any plan to "fix" it in future
> > FPGAs?
>
> > Can I assume that the ISE post-P&R static timing analysis will generate
> > an error if the BRAM address setup time will not be met?  I"m not sure
> > of the limitations of the static timing analysis, but I've never seen
> > any such error reported, so maybe my designs are OK.
>
> > Eric
>
The problem may have been around for many years and several device
generations. It obviously was a "sleeper", since nobody detected it,
or was bothered by it, in hundreds of millions of working systems.
There are no plans to"fix" it, since any change would severely reduce
the RAM performance,
Violating set-up time requirements just falls into the "don't do
that !" category.
Peter Alfke

> The problem is somewhat exotic. Violating address timing with respect
> to the clock would obviously always be a disaster when WE is active
> (You would write data into weird uncontrolled locations).
> Intuitively one might think that this should not be a problem in read
> mode, although the data output would of course be garbage.
> We had one user with asynchronously free-running address sequences,
> but his system ignored the output most of the time. He ws very
> surprised when he found the data contaminated. In his case the
> solution was trivial: Disable the BRAM whenever possible.
> I do not know about atomatic warnings.
> A clock is also called a "trigger", and it might be wise to remember
> the weapons-derived origin...
> Peter Alfke, Xilinx



Article: 125963
Subject: Re: Xilinx Parallel Cable IV, API spec
From: Antti <Antti.Lukats@googlemail.com>
Date: Sat, 10 Nov 2007 07:29:46 -0000
Links: << >>  << T >>  << A >>
On 10 Nov., 06:59, Eric Smith <e...@brouhaha.com> wrote:
> cs_post...@hotmail.com writes:
> > I this day and age you might as well use USB, getting you
> > compatability with your travel laptop, etc...
>
> However, if you want to write your own code to talk to the standard
> firmware of the Xilinx Platform USB Cable (rather than using Impact,
> Chipscope, and XMD), you'll probably *still* have to reverse-engineer
> the CPLD bits.

yes if you want to talk to ANY currently supported by xilinx cable you
need RE :(
only cable IV and usb cable are supported since xilinx has officially
dropped Cable III
support

Antti


Article: 125964
Subject: Re: Problem using xilinx usb download cable in linux
From: Michael Gernoth <mike@gernoth.net>
Date: Sat, 10 Nov 2007 12:07:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi,

On Sat, 03 Nov 2007 22:04:14 -0000, roger wrote:
> I have installed the usb-driver from http://www.rmdir.de/~michael/xilinx
> and I have managed to light up the green led to the usb download cable
> on the spartan 3e starter kit. The green led is going black every 6-8
> second and then green again.

I have not heard of this behaviour previously. For me this seems to
indicate that the cable gets dis- and reconnected all the time.
Do you see reoccuring dis-/reconnects in "dmesg".

> I don't manage to get a connection to the board using Impact. lsusb
> gives me the following:
>
> Bus 005 Device 012: ID 03fd:0008 Xilinx, Inc.
> [...]
> can't get device qualifier: Operation not permitted

What are the permissions on /dev/bus/usb/005/012 (or the current
location of the cable)? This error might show there is a permission
problem. You did add the MODE-line to an udev rules-file?

> and Impact says:
>
> Connecting to cable (Usb Port - USB21).
> Checking cable driver.
> File version of /usr/share/xusbdfwu.hex = 1025(dec), 0401.
>  libusb-driver.so version: 2007-10-08 15:43:55.
> Cable connection failed.

If you preload libusb-driver-DEBUG.so instead of libusb-driver.so you
get a much more detailed output, which could tell why impact does not
find the device (which according to your lsusb-output has the correct
firmware loaded).

Regards,
  Michael

Article: 125965
Subject: Re: FPGA Clock signal
From: Naive_Algorithm <yassermi@gmail.com>
Date: Sat, 10 Nov 2007 14:13:56 -0000
Links: << >>  << T >>  << A >>
On Nov 9, 12:42 pm, John LeVieux <jla...@yahoo.com> wrote:
> On Nov 8, 8:41 pm, raull...@hotmail.com wrote:
>
> > On Nov 7, 10:02 pm, John_H <newsgr...@johnhandwork.com> wrote:
>
> > > raull...@hotmail.com wrote:
> > > > i would like to ask how can i capture the FPGA master clock signal in
> > > > the oscilloscope? Bcos in the data sheet, it indicates that the master
> > > > clock is located at pin N9 which is not accessible externally. please
> > > > help. thanks a million
>
> > > Are you *sure* this signal is not externally accessible?  Typically the
> > > BGA package has a matrix of pads and vias.  The via for the clock signal
> > > should be exposed on the back of the board, ready for a steady hand to
> > > probe the clock right there "at" the package ball.
>
> > i am using the XEM3010 board. really have no idea how to tap the
> > signal. please help..
>
> Is there a schematic available in the XEM3010 documentation? If so, it
> should be possible to find another pin somewhere else on the board
> where the same clock signal can be probed with your oscilloscope.
>
> John LeVieux

I use BRK3010 the BreakOut Board for XEM3010 and it maps most pins to
an easy to probe test points. N9 is not mapped but I remember
measuring the PLL CLKA output on the XCLK1  Test point of the BRK3010
board.


Article: 125966
Subject: Re: FIFO interface design
From: John Retta <jretta@rtc-inc.com>
Date: Sat, 10 Nov 2007 10:04:31 -0700
Links: << >>  << T >>  << A >>
Readon wrote:
> On Nov 9, 10:54 am, Gabor <ga...@alacron.com> wrote:
>> On Nov 8, 8:25 pm, Readon <xydarc...@gmail.com> wrote:
>>
>>
>>
>>> On Nov 9, 8:07 am, Dave Pollum <vze24...@verizon.net> wrote:
>>>> On Nov 8, 8:15 am, Readon <xydarc...@gmail.com> wrote:
>>>>>    i want to read & write data to/from a fifo placed in fpga.  MCU's
>>>>> external bus is connected to the chip. I am using the sync-fifo ip of
>>>>> Altera CycloneII. The data bus and control signal are connected to
>>>>> fifo directly. it's unfortune that when i read once from bus, data
>>>>> would be read twice from fifo because there are two clock rising edges
>>>>> during read signal(low active) is resetted. I think it will read more
>>>>> datas from fifo if the read signal is resetted long enough.
>>>>>    Is there any good design for fifo interface connecting on the
>>>>> exteranl bus?
>>>> Using a Synchronous FIFO implies that the read clock and the write
>>>> clock are in the same clock domain.  Is your MCU supplying the FIFO's
>>>> clock or is the FPGA supplying the MCU's clock?  If the clock sources
>>>> are different, then you either need an Asynchronous FIFO, or you need
>>>> to run the MCU and FPGA from the same clock.
>>>> HTH
>>>> -Dave Pollum
>>> It is in different clock, i tried altera's asynchronous FIFO which
>>> need two extra clock for reading.
>>> is there any better solution?
>> If your MCU is running much slower than the FPGA, you can use the
>> FPGA's internal clock to run the synchronous FIFO, and a little
>> state logic to generate the necessary (single cycle) pulses for
>> read and write from the MCU interface signals.
> 
> unfortunately, the problem i met is on the contrary. MCU is much
> faster then FPGA, about 4 times.
> 

- Just for info purposes what is the fpga clk rate and MCU rate?
- What is the fastest clk available on pwb?
- Does the MCU provide a clk at all for this interface? ie synchronous
   interface?

Personally, I like to have an FPGA clk that is faster than any of my
interfaces, or I use a clk from the fastest source on the pwb, and make
my logic synchronous to that source, or I hope that if I have a high
speed interface, there is an external clk that I can use, and limit the
use of this clk within the fpga to just that interface..

That being said you are where you are.

You might want to look at using the clk multiplier function in the
Cyclone.  You will be able to generate a higher clk fpga rate than
you currently have, treat the read pulse asynchronously, and use the
trailing edge detect I previously described.  Since it is now 
asynchronous you will have to make the single FF, two FF and decode
your edge detect off of these signals.

-- 

Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

Colorado Based Xilinx Consultant

phone : 303.926.0068
email : jretta@rtc-inc.com
web   :  www.rtc-inc.com

Article: 125967
Subject: Re: Xilinx Parallel Cable IV, API spec
From: cs_posting@hotmail.com
Date: Sat, 10 Nov 2007 09:28:20 -0800
Links: << >>  << T >>  << A >>
On Nov 10, 12:59 am, Eric Smith <e...@brouhaha.com> wrote:
> cs_post...@hotmail.com writes:
> > I this day and age you might as well use USB, getting you
> > compatability with your travel laptop, etc...
>
> However, if you want to write your own code to talk to the standard
> firmware of the Xilinx Platform USB Cable (rather than using Impact,
> Chipscope, and XMD), you'll probably *still* have to reverse-engineer
> the CPLD bits.

But why would you want to use an expensive proprietary cable?

Get a cheap board with the cypress fx2 chip and implement a programmer
on that.

If you really want a manufacturer design for some reason, I believe
the working of the altera usb blaster has been explained well enough
that emulating it in an fx2 is possible.  Besides, wouldn't it be fun
to program a xilinx part with an (emulated) altera cable?


Article: 125968
Subject: Re: FIFO interface design
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 10 Nov 2007 17:53:22 GMT
Links: << >>  << T >>  << A >>
Readon wrote:
> On Nov 9, 10:54 am, Gabor <ga...@alacron.com> wrote:
>> On Nov 8, 8:25 pm, Readon <xydarc...@gmail.com> wrote:
>>> On Nov 9, 8:07 am, Dave Pollum <vze24...@verizon.net> wrote:
>>>> On Nov 8, 8:15 am, Readon <xydarc...@gmail.com> wrote:

>>>>>    i want to read & write data to/from a fifo placed in fpga.  MCU's
>>>>> external bus is connected to the chip. I am using the sync-fifo ip of
>>>>> Altera CycloneII. The data bus and control signal are connected to
>>>>> fifo directly. it's unfortune that when i read once from bus, data
>>>>> would be read twice from fifo because there are two clock rising edges
>>>>> during read signal(low active) is resetted. I think it will read more
>>>>> datas from fifo if the read signal is resetted long enough.
>>>>>    Is there any good design for fifo interface connecting on the
>>>>> exteranl bus?

>>>> Using a Synchronous FIFO implies that the read clock and the write
>>>> clock are in the same clock domain.  Is your MCU supplying the FIFO's
>>>> clock or is the FPGA supplying the MCU's clock?  If the clock sources
>>>> are different, then you either need an Asynchronous FIFO, or you need
>>>> to run the MCU and FPGA from the same clock.
>>>> HTH
>>>> -Dave Pollum

>>> It is in different clock, i tried altera's asynchronous FIFO which
>>> need two extra clock for reading.
>>> is there any better solution?

>> If your MCU is running much slower than the FPGA, you can use the
>> FPGA's internal clock to run the synchronous FIFO, and a little
>> state logic to generate the necessary (single cycle) pulses for
>> read and write from the MCU interface signals.

> unfortunately, the problem i met is on the contrary. MCU is much
> faster then FPGA, about 4 times.

I can get 600 Mb/s connections on a $5 FPGA.  I don't know any fast MCUs 
though the front side bus on some embedded processors can get pretty fast.

It sounds like you have an extremely simple logic problem.  The read 
from the MCU is too wide compared to the sync FIFO's clock.

Change that!  If you know that you'll only have one read during a read 
signal from the MCU, use that information to only assert the read 
control to the sync FIFO once.  *Do not* connect the double-wide read 
pulse directly to the MCU.  This is very, very simple logic.

Article: 125969
Subject: newbie to 16v8
From: Amit <amit.kohan@gmail.com>
Date: Sat, 10 Nov 2007 18:25:35 -0000
Links: << >>  << T >>  << A >>

Hello group,

I'm new to this field and currently learning how 16v8 architecture is
designed. Of course, pretty confused but as my first experiement I
need to implement a logical function and also design multiplier using
61v8.


does anybody know where I can get some information to be able to
complete this?

Regards,
amit


Article: 125970
Subject: Re: newbie to 16v8
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Sat, 10 Nov 2007 18:49:55 +0000
Links: << >>  << T >>  << A >>
On Sat, 10 Nov 2007 18:25:35 -0000, Amit <amit.kohan@gmail.com> wrote:

>
>Hello group,
>
>I'm new to this field and currently learning how 16v8 architecture is
>designed. Of course, pretty confused but as my first experiement I
>need to implement a logical function and also design multiplier using
>61v8.
>
>
>does anybody know where I can get some information to be able to
>complete this?

A GAL16V8, which I guess is what you mean, has only...
- 8 bits of storage
- 18 user I/O pins, of which one must be taken as a clock
  in most cases
so your multiplier surely cannot be very big! You could make
a multiplier with two 4-bit inputs and an 8-bit result...
probably.  If you have *lots* of 16V8s on a board, you 
could make a bigger multiplier.

When I did a Google search for GAL16V8, the first hit I found
was the Lattice data sheet.  (I used to know those devices 
inside-out, but I haven't used one for so long that I thought
I'd better remind myself of the details.)  Not a bad place to start.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 125971
Subject: Re: newbie to 16v8
From: Amit <amit.kohan@gmail.com>
Date: Sat, 10 Nov 2007 19:00:18 -0000
Links: << >>  << T >>  << A >>
On Nov 10, 10:49 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Sat, 10 Nov 2007 18:25:35 -0000, Amit <amit.ko...@gmail.com> wrote:
>
> >Hello group,
>
> >I'm new to this field and currently learning how 16v8 architecture is
> >designed. Of course, pretty confused but as my first experiement I
> >need to implement a logical function and also design multiplier using
> >61v8.
>
> >does anybody know where I can get some information to be able to
> >complete this?
>
> A GAL16V8, which I guess is what you mean, has only...
> - 8 bits of storage
> - 18 user I/O pins, of which one must be taken as a clock
>   in most cases
> so your multiplier surely cannot be very big! You could make
> a multiplier with two 4-bit inputs and an 8-bit result...
> probably.  If you have *lots* of 16V8s on a board, you
> could make a bigger multiplier.
>
> When I did a Google search for GAL16V8, the first hit I found
> was the Lattice data sheet.  (I used to know those devices
> inside-out, but I haven't used one for so long that I thought
> I'd better remind myself of the details.)  Not a bad place to start.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.


Hello Jonathan,

Thanks for your response. you are right,  I did download it but one
thing that I need to know how can I find a right flow? and associate
it with a multiplier 4 by 4?
it seems there are other controlling inputs such as Vcc (or maybe I'm
wrong) but is there any example of an adder for instance?

Once again thanks.
amit


Article: 125972
Subject: Re: FIFO interface design
From: Marlboro <ccon67@netscape.net>
Date: Sat, 10 Nov 2007 11:00:38 -0800
Links: << >>  << T >>  << A >>
On Nov 9, 10:56 pm, Readon <xydarc...@gmail.com> wrote:
> On Nov 9, 10:54 am, Gabor <ga...@alacron.com> wrote:
>
>
>
>
>
> > On Nov 8, 8:25 pm, Readon <xydarc...@gmail.com> wrote:
>
> > > On Nov 9, 8:07 am, Dave Pollum <vze24...@verizon.net> wrote:
>
> > > > On Nov 8, 8:15 am, Readon <xydarc...@gmail.com> wrote:
>
> > > > >    i want to read & write data to/from a fifo placed in fpga.  MCU's
> > > > > external bus is connected to the chip. I am using the sync-fifo ip of
> > > > > Altera CycloneII. The data bus and control signal are connected to
> > > > > fifo directly. it's unfortune that when i read once from bus, data
> > > > > would be read twice from fifo because there are two clock rising edges
> > > > > during read signal(low active) is resetted. I think it will read more
> > > > > datas from fifo if the read signal is resetted long enough.
> > > > >    Is there any good design for fifo interface connecting on the
> > > > > exteranl bus?
>
> > > > Using a Synchronous FIFO implies that the read clock and the write
> > > > clock are in the same clock domain.  Is your MCU supplying the FIFO's
> > > > clock or is the FPGA supplying the MCU's clock?  If the clock sources
> > > > are different, then you either need an Asynchronous FIFO, or you need
> > > > to run the MCU and FPGA from the same clock.
> > > > HTH
> > > > -Dave Pollum
>
> > > It is in different clock, i tried altera's asynchronous FIFO which
> > > need two extra clock for reading.
> > > is there any better solution?
>
> > If your MCU is running much slower than the FPGA, you can use the
> > FPGA's internal clock to run the synchronous FIFO, and a little
> > state logic to generate the necessary (single cycle) pulses for
> > read and write from the MCU interface signals.
>
> unfortunately, the problem i met is on the contrary. MCU is much
> faster then FPGA, about 4 times.- Hide quoted text -
>
> - Show quoted text -


Some how you need to synchronize your MCU read to the FIFO read clock
(edge detect as others said), then make sure the read connects to the
FIFO has 1 clock wide only

btw, building your own FIFO isn't difficult if the speed fairly "slow"






Article: 125973
Subject: Re: Why dynamic partial reconfiguration is still not there?
From: Adam Megacz <megacz@cs.berkeley.edu>
Date: Sat, 10 Nov 2007 11:42:40 -0800
Links: << >>  << T >>  << A >>

Mike Treseler <mike_treseler@comcast.net> writes:
>> My opinion is that the proprietary closed nature of FPGA hardware
>> and software tools is the big obstacle in this way.

Yes.

> If I had a great idea in this area, I would demonstrate it in
> simulation and then ring up a venture capitalist.

If every beneficial technology were commercially exploitable by a
small startup company I think the computing world would be quite a
different place.

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

Article: 125974
Subject: Re: Embedded Linux & Code Security
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Sat, 10 Nov 2007 20:44:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <b66e6525cd1c8c9f136acf9d755@news.ks.uiuc.edu>,
Matthew Hicks  <mdhicks2@uiuc.edu> wrote:
>In FPGAs, configurations can be stored in Flash in an encrypted format that 
>only the FPGA to be configured has the key to .  During configuration, the 
>FPGA does the encryption, so even data over the Flash to FPGA channel is 
>secure.  How the FPGA keeps it's key secure, I don't remember.  Maybe there 
>is an analogue to this in MCU land.

Specifically Altera Statrix-II FPGAs have AES 128 decryption and OTP (fuse)
non-readable key storage for the configuration bitstream.

So: run Linux on a NIOS soft core in one of these FPGAs.  Encrypt the code
in flash.  Add decryption units with keys to the memory interfaces (or limit
yourself to the memory built into the FPGA).  The decyption unit and keys
are encrypted in the Stratix-II bitstream, so they can't be read.

Even if you were able to read the fuse settings somehow, you would then have
to reverse-engineer the undocumented bit-stream format.

I think this is all bad, except for protecting nuclear weapons.  There would
be no hacked iPhones if its firmware was encrypted this well.  Vernor
Vinge's _Rainbow's End_ told about a computer engineer who could no longer
tinker with hardware due to her invention of a secure hardware environment.
-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}



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