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 98500

Article: 98500
Subject: Re: Learning new stuff about FPGA
From: Allan Herriman <allanherriman@hotmail.com>
Date: Sat, 11 Mar 2006 17:50:12 +1100
Links: << >>  << T >>  << A >>
On Sat, 11 Mar 2006 17:44:50 +1100, Allan Herriman
<allanherriman@hotmail.com> wrote:

>On Fri, 10 Mar 2006 16:05:02 +0800, "kcl" <KCLO4[no_spam]@free.fr>
>wrote:
>
>>Hi everybody,
>>
>>I am beginner in FPGA design ( about 1 year of experience in VHDL design), I 
>>enjoy my job but (there is always a but) I think I don't learn a lot of new 
>>thing about FPGA  since I have been out of my last internship .
>>So why I would like to know which book or website could you recommand me to 
>>enhance my knowledge. I' d like to learn about multiple clock domain design, 
>>making constraint (not only put a time constraint), interfacing fpga with 
>>the 'real wolrd' and all that hint & tips that make the difference betwen a 
>>good design and a beginner like me.
>
>
>Hi Alexis,
>
>You'll learn more by implementing real world designs.
>Your real world FPGA designs should be parts of real world products.
>That way you'll also learn about important aspects of engineering like
>marketing, customer interaction and support.
>
>Also, get yourself a mentor, i.e. someone who already knows about
>logic design and HDLs and can point out the pitfalls before you waste
>a lot of time with negative "learning experiences."

Sorry, my point was that this sort of learning doesn't come from books
or websites.  That isn't to say that you shouldn't read though :)

Another thing I forgot: 
it usually isn't apparent to neophytes that verification takes up a
significant part of a development schedule.

Allan

Article: 98501
Subject: Re: FPGA imple. of aes
From: Thomas Womack <twomack@chiark.greenend.org.uk>
Date: 11 Mar 2006 08:24:05 +0000 (GMT)
Links: << >>  << T >>  << A >>
In article <1142043401.992063.195710@e56g2000cwe.googlegroups.com>,
 <fpga_toys@yahoo.com> wrote:
>
>Thomas Womack wrote:
>> There has been a lot of research put into efficient implementations of
>> the S-boxes without using lookup tables;
>>
>> http://www.st.com/stonline/press/magazine/stjournal/vol00/pdf/art08.pdf
>>
>> might be an example.  I went to a conference in August where
>> http://class.ee.iastate.edu/tyagi/cpre681/papers/AESCHES05.pdf was
>> presented, which runs AES at 25Gbits/second on an XC3S2000; the round
>> function is pipelined into seven stages of three levels of LUT each.
>
>Any clue what the specific GF functions and tables are?

http://eprint.iacr.org/2004/134.pdf at the bottom of page six and top
of page seven gives a set of fields that you could use, but I'm afraid
I'm not really in the mood to explain GF(2^k) arithmetic in full
detail in a Usenet post, and on trying I've found that I can't
reconstruct the whole process without a fair amount of work; how much
do you know about it to begin with?

It's basically a generalisation of complex numbers to binary
arithmetic: start off with W defined so that W^2 = 1+W, and you have
[with a,b,c,d single bits]

(a+bW)(c+dW) = ac + (bc+ad)W + bdW^2 = (ac+bd) + (bc+ad+bd)W

(a+bW)^{-1} = (a+b) + bW

so, multiplication and inversion of things of the form a+bW are two
LUTs each. You then define X^2 = (something in 1 and W) + (something
in 1 and W)*X and repeat the process, using the definition of
inversion at the bottom of page 6 of the iacr preprint, to get
multiplication of four-bit expressions; you then define Y^2 =
(something in 1, X, W) + (something in 1,X,W)*Y and repeat again.

This is probably easiest done if you can find a spare mathematician to
lean over your shoulder while you're doing it, or ask on sci.crypt
where there will probably be someone who has the derivation handy:
good terms to google on are 'composite extensions' and 'towers of
fields'.

Tom


Article: 98502
Subject: Re: Plateform FLASH PROM configuration using a Microblaze.
From: "Marco T." <marc@blabla.com>
Date: Sat, 11 Mar 2006 09:24:46 +0100
Links: << >>  << T >>  << A >>

"Claude Sylvain" <claudesylvain@sympatico.ca> wrote in message 
news:NhsQf.5254$xM2.414382@news20.bellglobal.com...
> Hello all,
>
> In a project, I use a Spartan-3 XC3S400 FPGA from Xilinx.
>
> The design use a Microblaze CPU instantiated in the FPGA.
>
> I use the Digilent Spartan-3 starter kit for prototyping.  Note that the 
> original XC3S200 FPGA has been removed, and replaced by a XC3S400 FPGA.
>
> I want to erase/program the platform FLASH PROM installed in this board 
> (the XCF02S IC) with a new FPGA configuration file, using the Microblaze 
> CPU.
>
> Xilinx application note xapp544 is a good starting point for doing this 
> stuff. But, there are some information that is missing to be able to 
> achieve this task.  These informations are:
>
>    a) How long it take to program a PROM row (after the program row 
> command has been sent to the PROM) ?
>
>    b) What is the format a FPGA configuration file (.bit, .mcs, .hex), and 
> associated programmation algorithm to get the PROM programmed correctly ?
>
>
> I was searching for more than 1 week about this information without 
> finding anything.
> Is it possible that this information is confidential and can not be 
> published ?
>
>
> Claude Sylvain
> Electro-Technica inc.
>
>
>

Have you already seen XAPP482?
It explains how to store configuration file and software application into 
platform flash.

Marco 



Article: 98503
Subject: Re: Plateform FLASH PROM configuration using a Microblaze.
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 11 Mar 2006 09:29:51 +0100
Links: << >>  << T >>  << A >>

"Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag 
news:NhsQf.5254$xM2.414382@news20.bellglobal.com...
> Hello all,
>
> In a project, I use a Spartan-3 XC3S400 FPGA from Xilinx.
>
> The design use a Microblaze CPU instantiated in the FPGA.
>
> I use the Digilent Spartan-3 starter kit for prototyping.  Note that the 
> original XC3S200 FPGA has been removed, and replaced by a XC3S400 FPGA.
>
> I want to erase/program the platform FLASH PROM installed in this board 
> (the XCF02S IC) with a new FPGA configuration file, using the Microblaze 
> CPU.
>
> Xilinx application note xapp544 is a good starting point for doing this 
> stuff. But, there are some information that is missing to be able to 
> achieve this task.  These informations are:
>
>    a) How long it take to program a PROM row (after the program row 
> command has been sent to the PROM) ?
>
>    b) What is the format a FPGA configuration file (.bit, .mcs, .hex), and 
> associated programmation algorithm to get the PROM programmed correctly ?
>
>
> I was searching for more than 1 week about this information without 
> finding anything.
> Is it possible that this information is confidential and can not be 
> published ?
>
>
> Claude Sylvain
> Electro-Technica inc.
>

you are partially right :( the full programming specs of platform flash are 
confidential and have never been made available.

however all the required info can be obtained by looking at BSDL files and 
SVF files. So I have sucesfully created custom programming software that can 
program platform flash directly from .BIT files

Antti








Article: 98504
Subject: Re: FPGA imple. of aes
From: "manjunath.rg@gmail.com" <manjunath.rg@gmail.com>
Date: 11 Mar 2006 00:38:33 -0800
Links: << >>  << T >>  << A >>
No i dont think you can implement hardware concepts of subpipeling that
too in non feedback mode in C so easily..anyway if you have a c to vhdl
converter do tell me


Article: 98505
Subject: Re: (no subject)
From: "Antti" <Antti.Lukats@xilant.com>
Date: 11 Mar 2006 02:13:04 -0800
Links: << >>  << T >>  << A >>
nice accident !

at least we know that number 5 isnt skipped in the Virtex roadmap ;)

Antti


Article: 98506
Subject: Re: Learning new stuff about FPGA
From: "Hendra" <u1000393@email.sjsu.edu>
Date: 11 Mar 2006 02:42:42 -0800
Links: << >>  << T >>  << A >>
kcl wrote:
> So why I would like to know which book or website could you recommand me to
> enhance my knowledge. 

www.engr.sjsu.edu/crabill

Hendra


Article: 98507
Subject: Re: FPGA imple. of aes
From: fpga_toys@yahoo.com
Date: 11 Mar 2006 04:47:10 -0800
Links: << >>  << T >>  << A >>

manjunath.rg@gmail.com wrote:
> No i dont think you can implement hardware concepts of subpipeling that
> too in non feedback mode in C so easily..anyway if you have a c to vhdl
> converter do tell me

Pipelines in C are relatively easy at the statement level, just
requires reversing statement order.

a = 1;
b = a;
c = b;

propagates 1 to c with sequential execution.

for(;;) {
c = b;
b = a;
a = 1;
}

requires three clocks before c obtains the 1 value, three clock latency
pipeline that trickles up ward.


Article: 98508
Subject: Re: FPGA imple. of aes
From: fpga_toys@yahoo.com
Date: 11 Mar 2006 05:22:08 -0800
Links: << >>  << T >>  << A >>

Thomas Womack wrote:
> This is probably easiest done if you can find a spare mathematician to
> lean over your shoulder while you're doing it, or ask on sci.crypt
> where there will probably be someone who has the derivation handy:
> good terms to google on are 'composite extensions' and 'towers of
> fields'.

Thanks Tom. My math skills date back to very early 70's, and have not
needed to progress past that for most of the hardware/software
engineering I've done since.  I do have a general interest in crypto
stuff, and would probably need a math guy with some patience to walk me
thru it.

I did take the Deamon example code for study this morning, and while
not suitable for FPGA implementation because of the all the serialized
looping it was enough to understand the core algorithm pretty quickly.
I re-wrote it into a fully unrolled subset C for FpgaC in a couple
hours that is highly parallel, and pipelined at each round. The Sbox's
are just stubbed out with a define macro, waiting for something
reasonable to place in the macro. It appears that it should run at a
pretty fair clip once someone can provide a set of C statements for the
Sbox implementation you have reference.

it does suffer a bit from a long standing problem we inherited from
TMCC, which is that it doesn't know how to map F5/F6 muxes for
extending 4-LUT equations, and tends to push terms down a little too
quickly forcing a slightly deeper logic tree than optimal. This is also
impacting the PCI core I started as demo code a few weeks ago.

So,  I'm off re-writting the FpgaC bottom end code to solve that
problem for good. After the mux fixes, it appears FpgaC can compile the
AES engine to netlist very well, along with the earlier RSA demo code's
barrel shifters.

John


Article: 98509
Subject: Re: Plateform FLASH PROM configuration using a Microblaze.
From: "Claude Sylvain" <claudesylvain@sympatico.ca>
Date: Sat, 11 Mar 2006 11:58:43 -0500
Links: << >>  << T >>  << A >>
Yes, I seen it.

Unfortunatly, it do not include the information I want.
The way the information is stored inside the configuration file, so I can build 
my own program to read and program the PROM.


Claude Sylvain
Electro-Technica inc.



"Marco T." <marc@blabla.com> wrote in message news:duu1gb$bfh$1@nnrp.ngi.it...
>
> "Claude Sylvain" <claudesylvain@sympatico.ca> wrote in message 
> news:NhsQf.5254$xM2.414382@news20.bellglobal.com...
>> Hello all,
>>
>> In a project, I use a Spartan-3 XC3S400 FPGA from Xilinx.
>>
>> The design use a Microblaze CPU instantiated in the FPGA.
>>
>> I use the Digilent Spartan-3 starter kit for prototyping.  Note that the 
>> original XC3S200 FPGA has been removed, and replaced by a XC3S400 FPGA.
>>
>> I want to erase/program the platform FLASH PROM installed in this board (the 
>> XCF02S IC) with a new FPGA configuration file, using the Microblaze CPU.
>>
>> Xilinx application note xapp544 is a good starting point for doing this 
>> stuff. But, there are some information that is missing to be able to achieve 
>> this task.  These informations are:
>>
>>    a) How long it take to program a PROM row (after the program row command 
>> has been sent to the PROM) ?
>>
>>    b) What is the format a FPGA configuration file (.bit, .mcs, .hex), and 
>> associated programmation algorithm to get the PROM programmed correctly ?
>>
>>
>> I was searching for more than 1 week about this information without finding 
>> anything.
>> Is it possible that this information is confidential and can not be 
>> published ?
>>
>>
>> Claude Sylvain
>> Electro-Technica inc.
>>
>>
>>
>
> Have you already seen XAPP482?
> It explains how to store configuration file and software application into 
> platform flash.
>
> Marco
> 



Article: 98510
Subject: Re: for all those who believe in ASICs....
From: austin <austin@xilinx.com>
Date: Sat, 11 Mar 2006 09:34:50 -0800
Links: << >>  << T >>  << A >>
Rob,

I am not saying ASIC business is decreasing.

In fact, I stated the dollars are increasing (on fewer design starts).

I am stating that the structured ASIC business has been a real money 
loser for the companies that are toughing it out.  And, that there are 
companies leaving that business because "there is no money" (Toshiba's 
quote, not mine).

So, do not misquote me.  ASIC's $ increase; structured ASIC $ ? (unknown 
if it will increase or decrease, but you may be sure that companies will 
have a hard time making money  if they continue to pretend it is a one 
or two mask operation).

155M$ is the whole MARKET (IN 2005, ISuppli).  That was spread over as 
many as 12 companies in that year.  LSI had the largest share of that, 
at 35M$.  Everyone one else had a smaller chunk that 35M$.

Now, I ask you, if you had to assign dozens of IC Designers, software, 
and support people (perhaps this number is in the 100's) to support a 
business, how hard is it to do an ROI?

One must have assumed that the entire market was just going to explode, 
or the market was going to shake out quickly.

I can understand optimism.  I can not understand believing that one 
could get even 50% of any market with so many competitors, and so many 
BIG competitors (IBM, Fujitsu, Toshiba ...).

I can see a BIG company making a ten year effort and realizing that the 
payback may not come for a long time, but even then, there is a board of 
directors, and that board has got to be pretty ugly right now. Wouldn't 
want to be in those board rooms explaining why the new star (Structured 
ASICs) are still losing money, and why they are draining resources, and 
knocking the gross margins down.

So, a simple review:

ASIC business = really HUGE $ and increasing.  Design starts slowing, 
and reducing due to equally HUGE NRE, and issues with ultra deep 
submicron technolgy leading to expensive failures (or too many million $ 
mask sets).

Companies making business decisions to no longer use ASICs (losing too 
much money, time, etc.).

FPGA business picking up lots of what used to be ASIC business.

ASIC IC designers looking for jobs (we are hiring, send me your resume).

ASIC IC designers taking jobs designing with FPGAs.

Structured ASIC business looking shakey.  Were 13 players.  Now ten. 
Largest just threw in the towel.

Austin


Article: 98511
Subject: Re: Plateform FLASH PROM configuration using a Microblaze.
From: "Claude Sylvain" <claudesylvain@sympatico.ca>
Date: Sat, 11 Mar 2006 12:43:51 -0500
Links: << >>  << T >>  << A >>
I already found the BSDL description of the XCF02S PROM 
(http://www.xilinx.com/xlnx/xil_sw_updates_display.jsp?BV_UseBVCookie=yes&update=bsdl&software=PROMs).

But, I was not knowing anything about SVF files.  That was the missing chain !

Based on what I read in xapp503 
(http://www.xilinx.com/bvdocs/appnotes/xapp503.pdf), the steps I will have to 
do are:

    a) Convert the .bit configuration file to an .svf file, using iMPACT.

    b) Build a custom program to read, interpret and program the .svf file into 
the PROM, using the Microblaze CPU.


I don't still know the time it takes to program a PROM row.  Maybe it is in the 
XCS02S BSDL file, and I have missed it.  Nervertless, it can be optained by 
doing iterative test.


Thank you for your help.  That's exactly the information I want.

Claude Sylvain
Electro-Technica inc.




"Antti Lukats" <antti@openchip.org> wrote in message 
news:duu1tq$obg$1@online.de...
>
> "Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag 
> news:NhsQf.5254$xM2.414382@news20.bellglobal.com...
>> Hello all,
>>
>> In a project, I use a Spartan-3 XC3S400 FPGA from Xilinx.
>>
>> The design use a Microblaze CPU instantiated in the FPGA.
>>
>> I use the Digilent Spartan-3 starter kit for prototyping.  Note that the 
>> original XC3S200 FPGA has been removed, and replaced by a XC3S400 FPGA.
>>
>> I want to erase/program the platform FLASH PROM installed in this board (the 
>> XCF02S IC) with a new FPGA configuration file, using the Microblaze CPU.
>>
>> Xilinx application note xapp544 is a good starting point for doing this 
>> stuff. But, there are some information that is missing to be able to achieve 
>> this task.  These informations are:
>>
>>    a) How long it take to program a PROM row (after the program row command 
>> has been sent to the PROM) ?
>>
>>    b) What is the format a FPGA configuration file (.bit, .mcs, .hex), and 
>> associated programmation algorithm to get the PROM programmed correctly ?
>>
>>
>> I was searching for more than 1 week about this information without finding 
>> anything.
>> Is it possible that this information is confidential and can not be 
>> published ?
>>
>>
>> Claude Sylvain
>> Electro-Technica inc.
>>
>
> you are partially right :( the full programming specs of platform flash are 
> confidential and have never been made available.
>
> however all the required info can be obtained by looking at BSDL files and 
> SVF files. So I have sucesfully created custom programming software that can 
> program platform flash directly from .BIT files
>
> Antti
>
>
>
>
>
>
> 



Article: 98512
Subject: Re: Plateform FLASH PROM configuration using a Microblaze.
From: "Antti Lukats" <antti@openchip.org>
Date: Sat, 11 Mar 2006 19:02:37 +0100
Links: << >>  << T >>  << A >>
"Claude Sylvain" <claudesylvain@sympatico.ca> schrieb im Newsbeitrag 
news:5%DQf.5551$xM2.463864@news20.bellglobal.com...
>I already found the BSDL description of the XCF02S PROM 
>(http://www.xilinx.com/xlnx/xil_sw_updates_display.jsp?BV_UseBVCookie=yes&update=bsdl&software=PROMs).
>
> But, I was not knowing anything about SVF files.  That was the missing 
> chain !
>
> Based on what I read in xapp503 
> (http://www.xilinx.com/bvdocs/appnotes/xapp503.pdf), the steps I will have 
> to do are:
>
>    a) Convert the .bit configuration file to an .svf file, using iMPACT.
>
>    b) Build a custom program to read, interpret and program the .svf file 
> into the PROM, using the Microblaze CPU.
>
>
> I don't still know the time it takes to program a PROM row.  Maybe it is 
> in the XCS02S BSDL file, and I have missed it.  Nervertless, it can be 
> optained by doing iterative test.
>
>
> Thank you for your help.  That's exactly the information I want.
>
> Claude Sylvain
> Electro-Technica inc.
>

the timing is in SVF file if you look at it :)
converting BIT to SVF makes real LARGE files,
you are better to convert to XSVF, or depending your
application just look at the SVF and implement the logic from there
it isnt so complicated. most of the problems I had were related to
special features of the XCF08P (parallel mode options) for XCF02s
there should not be much magic required

Antti 



Article: 98513
Subject: Re: synthesis time with XST
From: "beeraka@gmail.com" <beeraka@gmail.com>
Date: 11 Mar 2006 11:04:23 -0800
Links: << >>  << T >>  << A >>
What is the code that you are trying to run??
May be some one can help you if you can post the code snippet that you
are trying to run. 

--
Parag


Article: 98514
Subject: Re: ModelSim 6.0 v 5.7 Can't read file
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 11 Mar 2006 13:12:11 -0800
Links: << >>  << T >>  << A >>
Brad Smallridge wrote:
> When I upgrade(?) to ISE 7.1.4 and ModelSim 6.0
> I find my testbenches can not read binary files. 

Try downloading and running this example
and see if the resulting
./char_file.bin matches the source comments.

http://home.comcast.net/~mike_treseler/char_file.vhd

vcom char_file.vhd
vsim -c char_file -do "run 1";

It works fine for me using Modelsim 6.1c.


         -- Mike Treseler

Article: 98515
Subject: Re: EDK: choices for simple internal control
From: "MM" <mbmsv@yahoo.com>
Date: Sat, 11 Mar 2006 17:23:51 -0500
Links: << >>  << T >>  << A >>
I have already posted this in a different thread, but I thought it might be
worth repeating the result. Bringing out the secondary side of the bridge
wasn't enough. In the end I had to create a custom IP, which I called
dcr_plug. It simply connects to the DCR master on one side and exposes the
same pins on the other side. This finally made the tool happy... So, now I
have the DCR bus in my top level design and I can do anything I want with
it!

/Mikhail



Article: 98516
Subject: Re: ModelSim 6.0 v 5.7 Can't read file
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Sat, 11 Mar 2006 16:29:21 -0800
Links: << >>  << T >>  << A >>
Yeah. That runs. Funny.

Here's my code:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

ENTITY tb IS
END tb;

ARCHITECTURE behavior OF tb IS

 component top
 port (
 clk         : in std_logic;
 reset       : in std_logic;
 vframe_in   : in std_logic;  -- 1 when the image is valid
 vline_in    : in std_logic;  -- 1 when the line is valid
 vblob  : out std_logic;
 vin    : in  std_logic_vector(7 downto 0);
 vred   : out std_logic_vector(7 downto 0);
 vgreen : out std_logic_vector(7 downto 0);
 vblue  : out std_logic_vector(7 downto 0)  );
 end component;

 signal clk        :  std_logic;
 signal reset      :  std_logic;
 signal vframe_in  :  std_logic;
 signal vline_in   :  std_logic;
-- signal vline_out  :  std_logic;
 signal vblob  :  std_logic;
 signal vin    :  std_logic_vector(7 downto 0);
 signal vred   :  std_logic_vector(7 downto 0);
 signal vgreen :  std_logic_vector(7 downto 0);
 signal vblue  :  std_logic_vector(7 downto 0);

 constant start_recording_row_delay : integer := 2;
 constant start_recording_col_delay : integer := 8;

 constant clkperiod    : time := 20 ns;
 constant line_synchs  : integer := 4;

 type     char_file is file of character;  -- one byte each

 file     my_file    : char_file;
 file     my_file2   : char_file;

 constant file_name  : string := "infile.bmp";
 constant file_name2 : string := "outfile.bmp";

 type int_array  is array(53 downto 0) of integer;
 type char_array is array(53 downto 0) of character;

 signal bmp_char:char_array;
 signal start_recording : std_logic;
 signal row_counter : std_logic_vector(15 downto 0);


   function bmp_function(
   bmp_header:int_array;
   bmp_start, bmp_data_size : integer
   ) return integer is
   variable result : integer;
   variable multiplier : integer;
   variable bmp_pointer : integer;
   begin
 result := 0;
 multiplier := 1;
 bmp_pointer := bmp_start;
     for i in 0 to (bmp_data_size-1) loop
   result := result + multiplier*bmp_header(bmp_pointer);
   multiplier := multiplier*256;
   bmp_pointer := bmp_pointer+1;
     end loop;
-- result_vector := 
std_logic_vector(to_unsigned(result,result_vector'length));
   return result;
   end function bmp_function;

  --BMP Header
      signal file_size : std_logic_vector(31 downto 0);
      signal reserved1 : std_logic_vector(31 downto 0);
      signal reserved2 : std_logic_vector(31 downto 0);
      signal offset : std_logic_vector(31 downto 0);

  --BMP Info
      signal size : std_logic_vector(31 downto 0);
      signal width : std_logic_vector(31 downto 0);
      signal height : std_logic_vector(31 downto 0);
      signal planes : std_logic_vector(31 downto 0);
      signal bits : std_logic_vector(31 downto 0);
      signal compression : std_logic_vector(31 downto 0);
      signal imagesize : std_logic_vector(31 downto 0);
      signal xresolution : std_logic_vector(31 downto 0);
      signal yresolution : std_logic_vector(31 downto 0);
      signal ncolors : std_logic_vector(31 downto 0);
      signal importantcolors : std_logic_vector(31 downto 0);

BEGIN

 uut: top PORT MAP(
  clk => clk,
  reset => reset,
  vframe_in  => vframe_in,
--  vframe_out => vframe_out,
  vline_in   => vline_in,
--  vline_out  => vline_out,
  vblob => vblob,
  vin => vin,
  vred => vred,
  vgreen => vgreen,
  vblue => vblue
 );


 clock_process: process
 begin
   clock_loop: loop
     clk <='0';
     wait for 5 ns;
     clk <='1';
     wait for 10 ns;
     clk <='0';
     wait for 5 ns;
   end loop clock_loop;
 end process clock_process;

 data_recording:process
 variable dr_my_char_v      : character;
 variable dr_int         : integer;
 variable dr_imagesize_var  : integer;
 variable dr_height_var     : integer;
 variable dr_width_var      : integer;
 variable dr_column_counter : integer;
 variable dr_row_counter_var: integer;
 begin
 start_recording <= '0';

    wait for clkperiod; -- let the other process go first
    wait for clkperiod; -- let the other process go first
    wait for clkperiod; -- let the other process go first
--    wait for clkperiod; -- let the other process go first
--    wait for clkperiod; -- let the other process go first

   -- convert std_logic_vectors to integers so that
   -- we can use multiple and divide operators
   dr_imagesize_var  := to_integer(unsigned(imagesize));
   dr_height_var     := to_integer(unsigned(height));
   dr_width_var      := to_integer(unsigned(width));
   dr_column_counter := 0;

   -- wait for the image to pass through the various row delays
   --      of the hardware before starting to record
   dr_row_counter_var := to_integer(unsigned(row_counter));
   while( dr_row_counter_var < start_recording_row_delay ) loop
      wait for clkperiod;
     dr_row_counter_var := to_integer(unsigned(row_counter));
   end loop;

   -- now wait a number of hardware column delays
   for dr_col_start in 0 to (start_recording_col_delay -1) loop
      wait for clkperiod;
   end loop;

   -- and now start recording output
   start_recording <= '1';
   for dr_row in 0 to (dr_height_var-1) loop
     for dr_col in 0 to (dr_width_var-1) loop
        wait for clkperiod;
       -- write three bytes of RGB data into the bmp file
       -- for each pixel/clock from the hardware
       dr_int := to_integer(unsigned(vblue));
       dr_my_char_v   := character'val(dr_int);
       write(my_file2,dr_my_char_v);
       dr_int := to_integer(unsigned(vgreen));
       dr_my_char_v   := character'val(dr_int);
       write(my_file2,dr_my_char_v);
       dr_int := to_integer(unsigned(vred));
       dr_my_char_v   := character'val(dr_int);
       write(my_file2,dr_my_char_v);
     end loop;

     -- pad the end of line with extra bytes
     -- for those BMP files that have widths
     -- that are not even multiples of 4
     if( dr_imagesize_var/dr_height_var > (3*dr_width_var) ) then
       for col in 1 to (dr_imagesize_var/dr_height_var-(3*dr_width_var)) 
loop
         dr_my_char_v := character'val(0);
         write(my_file2,dr_my_char_v);
       end loop;
     end if;

     -- end of line delay
     for col in 1 to line_synchs loop
       wait for clkperiod;
     end loop;
   end loop;

   file_close(my_file2);
   file_close(my_file);
   report "Success" severity failure;  -- failure will end it
 end process;

 tb : process
 variable bmp_header : int_array;

 variable tb_blue_char : character;
 variable tb_green_char : character;
 variable tb_red_char : character;
 variable tb_fill_char : character;

 variable tb_blue_int : integer;
 variable tb_green_int : integer;
 variable tb_red_int : integer;

 variable bluevalue : integer;
 variable greenvalue : integer;
 variable redvalue : integer;
 variable grayvalue : integer;

 variable vinblue   : character;
 variable vingreen  : character;
 variable vinred    : character;

  --BMP Header
      variable file_size_var : integer;
      variable reserved1_var : integer;
      variable reserved2_var : integer;
      variable offset_var    : integer;
  --BMP Info
      variable size_var        : integer;
      variable width_var       : integer;
      variable height_var      : integer;
      variable planes_var      : integer;
      variable bits_var        : integer;
      variable compression_var : integer;
      variable imagesize_var   : integer;
      variable xresolution_var : integer;
      variable yresolution_var : integer;
      variable ncolors_var     : integer;
      variable importantcolors_var : integer;

      variable row_count_var     : integer;

   begin

 file_open(my_file, file_name, read_mode);
 file_open(my_file2, file_name2, write_mode);

 for i in 0 to 53 loop
   read(my_file, tb_fill_char);
   bmp_header(i) := character'pos(tb_fill_char);
   bmp_char(i) <= tb_fill_char;
   write(my_file2,tb_fill_char);
 end loop;

 -- the first byte of a BMP file is a B
 assert bmp_header(0) = character'pos('B')
     report "first char not B" severity warning;

-- Brad Smallridge Ai Vision

 -- the second byte of a BMP file is an M
 assert bmp_header(1) = character'pos('M')
     report "second char not M" severity warning;

 -- here is the read BMP header in signal form
 file_size_var   := bmp_function(bmp_header,2,4);
 reserved1_var   := bmp_function(bmp_header, 6,2);
 reserved2_var   := bmp_function(bmp_header, 8,2);
 offset_var      := bmp_function(bmp_header,10,4);
 size_var        := bmp_function(bmp_header,14,4);
 width_var       := bmp_function(bmp_header,18,4);
 height_var      := bmp_function(bmp_header,22,4);
 planes_var      := bmp_function(bmp_header,26,2);
 bits_var        := bmp_function(bmp_header,28,2);
 compression_var := bmp_function(bmp_header,30,4);
 imagesize_var   := bmp_function(bmp_header,34,4);
 xresolution_var := bmp_function(bmp_header,38,4);
 yresolution_var := bmp_function(bmp_header,42,4);
 ncolors_var     := bmp_function(bmp_header,46,4);
 importantcolors_var := bmp_function(bmp_header,50,4);

 -- bmp header variables converted to signals
     file_size   <= std_logic_vector(to_unsigned(file_size_var, 
file_size'length));
     reserved1   <= std_logic_vector(to_unsigned(reserved1_var, 
reserved1'length));
     reserved2   <= std_logic_vector(to_unsigned(reserved2_var, 
reserved2'length));
     offset      <= std_logic_vector(to_unsigned(offset_var, 
offset'length));
     size        <= std_logic_vector(to_unsigned(size_var, size'length));
     width       <= std_logic_vector(to_unsigned(width_var, width'length));
     height      <= std_logic_vector(to_unsigned(height_var, 
height'length));
     planes      <= std_logic_vector(to_unsigned(planes_var, 
planes'length));
     bits        <= std_logic_vector(to_unsigned(bits_var, bits'length));
     compression <= std_logic_vector(to_unsigned(compression_var, 
compression'length));
     imagesize   <= std_logic_vector(to_unsigned(imagesize_var, 
imagesize'length));
     xresolution <= std_logic_vector(to_unsigned(xresolution_var, 
xresolution'length));
     yresolution <= std_logic_vector(to_unsigned(yresolution_var, 
yresolution'length));
     ncolors     <= std_logic_vector(to_unsigned(ncolors_var, 
ncolors'length));
     importantcolors <= std_logic_vector(to_unsigned(importantcolors_var, 
importantcolors'length));

 if( ncolors_var > 0 ) then
   report "bmp file not 24 bit type" severity failure;
 end if;

 reset <= '1';
 vframe_in <= '0';
 vline_in  <= '0';
 vin    <= (others=>'0');

 row_counter <= (others=>'0');
 row_count_var := 0;

  wait for clkperiod;

 reset <= '0';
  wait for clkperiod;

  vframe_in <= '1';
  wait for clkperiod;

  wait for clkperiod;

  for row in 0 to (height_var-1) loop

   vline_in <= '1';
   row_count_var := row_count_var+1;
       row_counter <=
   std_logic_vector(to_unsigned(row_count_var, row_counter'length));

--   report "row" severity warning;

   for col in 0 to (width_var-1) loop
   read (my_file, vinblue);
   read (my_file, vingreen);
   read (my_file, vinred);
   bluevalue  := character'pos(vinblue);
   redvalue   := character'pos(vingreen);
   greenvalue := character'pos(vinred);
   grayvalue  := (bluevalue + greenvalue + redvalue)/3;

   vin <= std_logic_vector(to_unsigned(grayvalue,vin'length));

   wait for clkperiod;

   end loop;

   -- Signal end of line to uut by dropping vline.
   -- Do a number of end of line clocks.
   -- Pull and write delayed response from vouts.

   -- If this loop is too short the output image
   -- will have a black streak, this is a bug in
   -- the timing.
   for col in 1 to line_synchs loop
     vline_in <= '0';
     vin <= (others=>'0');
     wait for clkperiod;

   end loop;

--   -- Pad the file output end of a line with extra bytes
--   --   to satisfy 4n address boundaries
   if( imagesize_var/height_var > (3*width_var) ) then
     for col in 1 to (imagesize_var/height_var-(3*width_var)) loop
     read (my_file, tb_fill_char);
     end loop;
   end if;

 end loop;

 vframe_in <= '0';

 file_close(my_file);

  end_of_input:loop
   -- keep vline_in going to flush output
   vline_in <= '1';
   row_count_var := row_count_var+1;
       row_counter <=
   std_logic_vector(to_unsigned(row_count_var, row_counter'length));
--   vin <= (others=>'0'); -- for light pixel detection
   vin <= (others=>'1'); -- for  dark pixel detection
   for col in 0 to (width_var-1) loop
     wait for clkperiod;
   end loop;
   vline_in <= '0';
   for col in 1 to line_synchs loop
     wait for clkperiod;
   end loop;
 end loop end_of_input;


   end process tb;

end;



Article: 98517
Subject: Re: for all those who believe in ASICs....
From: "Rob" <robnstef@frontiernet.net>
Date: Sun, 12 Mar 2006 03:44:52 GMT
Links: << >>  << T >>  << A >>
> Did you get a Hardcopy II price from Altera, or is that what you mean here 
> ?

Prices were from Altera and Rapid Chip.  And both vendors came back with 
similar pricing.  The ASIC is being done by KLSI.  KLSI's NRE was also very 
reasonable.

> Do you have any current consumption ratios ?

No, I don't have this information presently at hand.



"Jim Granville" <no.spam@designtools.co.nz> wrote in message 
news:441261f2$1@clear.net.nz...
> Rob wrote:
>> Austin,
>>
>>
>>>Let those nine companies circle the drain, the plug has been pulled.
>>
>>
>> I'm really having great difficulty trying to understand why you think the 
>> ASIC/ structured ASIC market is going to die.  Can you give us Xilinx's 
>> roadmap/business model that will compete?
>
>  Don't forget Xilinx have a (large) vested interest in talking down any 
> ASIC MASK flows.
>
>
>> For instance: can you give me a 60k/annum pricing for a product that has 
>> a 3yr life--total pcs 180k of a 375k Gate device with 3Mbit of on chip 
>> ram and 4 PLL's?  And I'll compare it to my quote from our ASIC vendor. 
>> When we started this design we were in a V2PRO30, since then our design 
>> has grown beyond the limits of this device.  But since I only have 
>> pricing on the V2P30 my math will have to be based on this part.  I will 
>> only give percentages as it would not be prudent for me to reveal the 
>> actual numbers.
>>
>> The ASIC is 8x cheaper than the V2P part.  How much more lower would the 
>> ASIC be when compared to an FPGA that could hold our current design?  It 
>> is very easy to see that we save the company BIG $$ by going to an ASIC. 
>> The structured ASIC pricing was approx 4x cheaper, which is still very 
>> much cheaper than going with an FPGA.
>
> Did you get a Hardcopy II price from Altera, or is that what you mean here 
> ?
>
> Do you have any current consumption ratios ?
>
>> Xilinx has decided to ignore this market, based on one of your 
>> posts--155M is too small for a 2B dollar company.
>
>  That has to be a very hard number to quantify reliably - for example, I 
> doubt if Altera's HardCopy is in that pigenhole, they will be called 
> FPGA's.
>  Altera only has to hit ~15% revenue via HardCopy, to equal that number.
>
>  Another way to approach this, is the FSA just said their members hit
> $40B last year, and they are only a portion of FAB runs.
> TSMC alone is presently close to $10B/yr, at the FAB end.
>
>  Everything a FAB makes, is an ASIC - a large chunk will not be reachable 
> by FPGAs due to sheer low power, or Analog features ( tho Actel can start 
> to argue on that last point, at least for average analog features ).
>
> -jg
>
>
> 



Article: 98518
Subject: Re: for all those who believe in ASICs....
From: "Rob" <robnstef@frontiernet.net>
Date: Sun, 12 Mar 2006 04:17:59 GMT
Links: << >>  << T >>  << A >>
Austin,

> So, do not misquote me.  ASIC's $ increase; structured ASIC $ ? (unknown 
> if it will increase or decrease, but you may be sure that companies will 
> have a hard time making money  if they continue to pretend it is a one or 
> two mask operation).

Misquote you?  I took your comment about circling the drain to mean that it 
would only be a matter of time before the remaining players would bow out of 
the business.  What else could circling the drain mean?  My post was not 
meant to address the "time" part of your quote; but rather question what is 
it about the current market environment that would cause this flushing of 
the remaining players.  And what is in Xilinx's future roadmap that would 
help facilitate this flushing, oh I'm sorry I mean cleansing.  Because, 
currently, for products with large numbers, FPGA's are too expensive and 
don't offer the same performance.  What I think I missed was that you're 
referring only to the structured ASIC business, and not the ASIC.

I would tend to agree that the future of the structured ASIC business is a 
bit nebulous.  Especially after receiving the numbers on our latest RFQ 
submittals.   The NRE on the ASIC was surprisingly competitive with the 
structured ASIC path.   About all the structured ASIC offered was a quicker 
delivery by approx 3-4 months.

> ASIC IC designers looking for jobs (we are hiring, send me your resume).

I'll keep you in my rolodex if indeed your premonition comes true!

Best regards,
Rob

"austin" <austin@xilinx.com> wrote in message 
news:duv1n0$p816@xco-news.xilinx.com...
> Rob,
>
> I am not saying ASIC business is decreasing.
>
> In fact, I stated the dollars are increasing (on fewer design starts).
>
> I am stating that the structured ASIC business has been a real money loser 
> for the companies that are toughing it out.  And, that there are companies 
> leaving that business because "there is no money" (Toshiba's quote, not 
> mine).
>
> So, do not misquote me.  ASIC's $ increase; structured ASIC $ ? (unknown 
> if it will increase or decrease, but you may be sure that companies will 
> have a hard time making money  if they continue to pretend it is a one or 
> two mask operation).
>
> 155M$ is the whole MARKET (IN 2005, ISuppli).  That was spread over as 
> many as 12 companies in that year.  LSI had the largest share of that, at 
> 35M$.  Everyone one else had a smaller chunk that 35M$.
>
> Now, I ask you, if you had to assign dozens of IC Designers, software, and 
> support people (perhaps this number is in the 100's) to support a 
> business, how hard is it to do an ROI?
>
> One must have assumed that the entire market was just going to explode, or 
> the market was going to shake out quickly.
>
> I can understand optimism.  I can not understand believing that one could 
> get even 50% of any market with so many competitors, and so many BIG 
> competitors (IBM, Fujitsu, Toshiba ...).
>
> I can see a BIG company making a ten year effort and realizing that the 
> payback may not come for a long time, but even then, there is a board of 
> directors, and that board has got to be pretty ugly right now. Wouldn't 
> want to be in those board rooms explaining why the new star (Structured 
> ASICs) are still losing money, and why they are draining resources, and 
> knocking the gross margins down.
>
> So, a simple review:
>
> ASIC business = really HUGE $ and increasing.  Design starts slowing, and 
> reducing due to equally HUGE NRE, and issues with ultra deep submicron 
> technolgy leading to expensive failures (or too many million $ mask sets).
>
> Companies making business decisions to no longer use ASICs (losing too 
> much money, time, etc.).
>
> FPGA business picking up lots of what used to be ASIC business.
>
> ASIC IC designers looking for jobs (we are hiring, send me your resume).
>
> ASIC IC designers taking jobs designing with FPGAs.
>
> Structured ASIC business looking shakey.  Were 13 players.  Now ten. 
> Largest just threw in the towel.
>
> Austin
> 



Article: 98519
Subject: Re: Plateform FLASH PROM configuration using a Microblaze.
From: Kolja Sulimma <news@sulimma.de>
Date: Sun, 12 Mar 2006 09:51:38 +0100
Links: << >>  << T >>  << A >>
Claude Sylvain schrieb:

>     b) Build a custom program to read, interpret and program the .svf file into 
> the PROM, using the Microblaze CPU.

There is a GPL licensed SVF player available:
https://ssl.keshi.org/projects/logic/trac.fcgi/browser/openwince/current/jtag/README.svf

Kolja Sulimma

Article: 98520
Subject: Re: fpga to 5v ttl logic
From: metal <nospam@spaam.edu>
Date: Sun, 12 Mar 2006 01:56:02 -0800
Links: << >>  << T >>  << A >>
On Sun, 26 Feb 2006 21:05:32 +1300, Jim Granville
<no.spam@designtools.co.nz> wrote:

>Peter Alfke wrote:
>> 5V should today be considered an obsolete and awkward supply voltage,
>> 
>
>Sorry Peter, but much as the FPGA sector wants 5V to go away,
>it's still here. 
>
>Why ? - noise immunity, ease of interface : have you ever tried to
>find a power MOSFET that can be driven from 3.3V ?
>
>-jg


agree 100%

it is the FPGA makers who are awkward; not the supply voltage.

imho, fpga makers have dropped the ball, by totally ignoring the
enormous markets of various mixed-signal products; where 5v is VERY
common...along with generally noisy environments.

I have always been amazed that not a single fpga-maker has made a line
of small-to-medium sized parts targeted not for blazing speed and
monster computing functions; but rather, for 5v I/O, all
Schmitt-trigger inputs, and very low cost.

Imho, such a line would sell like hotcakes.  Instead of hard-silicon
MAC's and such, where are the hard-silicon counter/timer modules, etc.
??

I'd love to be able to buy a $5 part with 64 or 128 flops, and a hard
block of 8 timer/counters (hardly any chip area in modern silicon).
I've got =dozens= of apps for such a part.

In any case, it's not the users who are mistaken about 5v; but rather,
the fpga-makers...who are ignoring the -reality- of -ongoing demand-
for it, instead of embracing it via a profitable targeted
product-line.

just m-h-o as one of those pesky 5v users, of course... <g>



----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---

Article: 98521
Subject: Re: (no subject)
From: Eric Smith <eric@brouhaha.com>
Date: 12 Mar 2006 02:09:06 -0800
Links: << >>  << T >>  << A >>
"Antti" <Antti.Lukats@xilant.com> writes:
> nice accident !
> at least we know that number 5 isnt skipped in the Virtex roadmap ;)

Assuming that the Marketing department doesn't rename it before offical
introduction.  Things like that sometimes happen.

Presumably the Virtex 5 (or whatever it's going to be called) is the
65 nm part mentioned in a recent Xilinx press release.

What I'd like to see on the roadmap would be some very-low-leakage
Spartan parts, for use in battery powered devices.  They wouldn't need
to be anywhere near as fast as the Spartan 2, nor as dense.  Maybe it
could be done with thick oxide in 180, 250, or perhaps even 350 nm.
Gotta do soemthing with all that excess fab capacity in older processes;
might as well make low-leakage FPGAs.  :-)

Alternatively, big low-power CPLDs with some RAM blocks would be nice.
Once upon a time Intel made some medium-ish sized ones (by the standards
of that time) in which each group of macrocells could be reconfigured
as a small RAM.  Then they transferred the product to Altera and it
was quickly discontinued.  Sigh.

Article: 98522
Subject: Re: fpga to 5v ttl logic
From: Eric Smith <eric@brouhaha.com>
Date: 12 Mar 2006 02:16:06 -0800
Links: << >>  << T >>  << A >>
metal <nospam@spaam.edu> writes:
> Instead of hard-silicon
> MAC's and such, where are the hard-silicon counter/timer modules, etc.

A good MAC is fairly complicated, and as a soft MAC takes up lots of
FPGA real estate, so it makes sense to stick one or two on the die of
larger parts since it's then a fairly small percentage of the part.  Not
all the customers benefit, but some benefit a lot, and the others aren't
penalized much.

But counter-timers don't take up much room in an FPGA, so if you go to
hardwiring those, you don't gain anything, and you lose tons of flexibility.
Inevitably the features of the hardwired timer-counter would never be quite
what you need for any given design.  There would be only a small penalty,
but it would be borne by all customers.  Very few would get any advantage,
and the advantage would be very modest.  The cost/benefit analysis is
much worse than with a MAC.

If you want them to build some other hardwired logic into their FPGAs, you'll
need to come up with a *much* better example than that.

Eric

Article: 98523
Subject: Re: Combinatorial Division?
From: metal <nospam@spaam.edu>
Date: Sun, 12 Mar 2006 03:26:29 -0800
Links: << >>  << T >>  << A >>
On 27 Feb 2006 13:12:21 -0800, "logjam" <grant@cmosxray.com> wrote:

>I was thinking about a transistor based computer last night.  What kind
>of memory can I use in a transistor computer without cheating?  Core
>memory?  Should I just have a goal of "transistor CPU" and consider the
>ram a peripheral?
>


darn....looked like I missed a good party while I was away... :)

Peter, who -else- would've said they were building a 64b ALU from TTL
??   -Surely- you couldn't have possibly thought it was a commercial
design?  ROFL...
.
.
One of my best elex learning-experiences was repairing an RCA
all-xsistor computer in my teens.

logjam, I know you asked about division in regards to the big ALU; but
if you are also thinking about math for your all-transistor computer,
you might consider analog techniques as well.

The parts-count and board-space cost would be for an 8b AD/DA
implemented in discretes...but the payoff would be pretty fast
calc-times...perhaps on the order of single-cycles of the cycle-rate
your xsistor cpu is likely to run at (500khz maybe??).

8b accuracy isn't too difficult to achieve in discrete mult/div ckts.

Also, some switch-controlled rewiring can give you trig functions as
well...also at single-cycle speeds....

The parts-count for the math-section itself would likely be the same
or less than the AD/DA.  Of course, with a little thought, you can get
either of these functions down to a surprisingly low parts-count.
Ramp techniques are extremely simple...with conversion-speed
determined mostly by how fast you can count.

And there are topologies which might inherently -combine- both
functions into the same parts.  There are pulse-based techniques for
analog multiplication....quite accurate too...and temp-insensitive;
unlike log-element based ckts.  I'm just shooting from the hip here,
but it seems like this ought to combine nicely with counting-type
AD/DA conversion...

For memory logjam, how 'bout DRAM ??

With tiny smt xsistors and caps, you could achieve a reasonable
density.

Not as high as core, of course; but finding -undamaged- core planes is
getting harder all the time.  Sloppy handling always leaves one of
those microwires trashed...  And besides, you want to build it ALL
yourself, right?  <g>

I -think- the xsistor-count will still be lower than full static, even
after adding the addressing/writing xsistors; but I'm not sure of
that.  Have never implemented either.


hmmm....it must be getting late; as my mind is drifting over various
ways to implement memory with discretes... <g>

how 'bout, instead of using a xsistor-per-bit, you use a differential
scheme with only a single diff-amp as sense-amp?  Wire all the caps to
an X/Y (top/bottom) grid....somewhat like core...an 8b-to-256-line
decoder on each side of the grid charges/discharges the selected cap.

With a little thought to the design, you should be able to use 95% of
that same decoding parts-group to select a bit/cap for the sense-amp
as well....

And with a high enough refresh-rate, you could store a multi-bit value
per cap.  It would be interesting to see a 256x8 version.  At first
thought, I felt that 8b would be hard to achieve...but thinking about
the scale of this thing....you could easily be using 10-15v signals,
and caps of nanofarads rather than femtofarads...so 8b might not be
out of reach.

Effectively, you trade mem BW for storage-density...since your
refresh-rate will have to scale linearly with the required resolution.
i.e. 8b capability requires 4 times less V-sag than 1b (I think)...so
4 times the refresh rate.

hmmm a second time.....you know, you might be able to make a
destructive-readout version that wouldn't require any sense-amp and
sense-amp decoding at all, as such....

Say you implemented the sense-amp as a -current- sense, within the
write drivers themselves.  A read-cycle would just be a write-cycle,
but with monitoring.  If that bit was already charged, there wouldn't
be a (normal sized) current-pulse during the write.

I believe such destructive-read methods were the norm in core-memory.

(it's been a looong time since my working-at-DEC days... <g>)

Such a design would really simplify the peripheral circuits.  Again, I
would look at doing it differentially....so you only have to look for
the -direction- of the pulse; rather than measuring magnitude.

Oh, by the way, one more method before I hit the hay...which I was
surprised not to see mentioned; given the number of truly knowledgable
folks here, and the length of this thread....

Delay Lines.

Some early computing devices used delay-lines as serial storage
devices.

Find yourself a 1,000' roll of cheap catv coax at the junkyard for 5
bucks; and there ya go.

8 rolls gives you 8 bits...and if you arrange 'em right, you'll have
an interesting modern-art sculpture for the living room... <g>

hmm...actually, speed might be an issue with coax as the medium...

1,000' of coax is only a microsecond or so...and you need a LOT of
delay...

It used to be had by using ultrasonic methods via glass delay-lines;
some of which are still available, by the way...but which wouldn't be
a totally homebrew kind of thing...

Potentially, you could modulate a ghz osc. and beam it at a
water-tower 5-10 miles away...that'd give you 20us... <g>

by the way, disks are not just magnetic....  There were several "echo
boxes" made as guitar-effects back when, which used an electrostatic
technique of some sort on a rotating disk.

hmm....thinking about that reminded me of toner-drums...which reminded
me of the earlier mention of machining/coating drums.  Toner-drums are
electrostatic of course; but may possibly have magnetically-usable
properties...

also, CRT's have been used for data-storage...  I think they normally
were purpose-made, with some sort of electrical readout of the charge
on the plate...but you might also work up an optical read method to
use with standard CRT's...


pps;  on the delay-line method....thinking of ultrasonics....forget
solid mediums altogether, and simply -beam- sound at some distant
reflector or repeater.  1100' per second, if memory serves...so you
could get quite a bit of delay/storage within practical distances.

Although I've never tried it, it's also possible that you could use a
100' roll of, say, 1/2" copper-tubing from the hdw-store as a
waveguide.  You'd have to have a high-enough frequency to be above
cutoff of course...and I'm too zoned to calc that right now.  That'd
give you roughly 100ms of delay; which might be a fair bit of data...

Old ultrasonic remote-control transducers would work for this app.
Direct-tv style parabolic dishes would be suitable for the open-beam
technique..  Transducers for depth-sounders ("fish finders") are
powerful and fairly high frequency.  I'm thinking that the higher the
freq, the higher the bit-density and transfer rate you can achieve.

wow....fish-finders....-definitely- time to hit the hay... <g>


ps;  I admire what you're doing; and have done similar things myself
just for the love of doing it.  go for it !


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---

Article: 98524
Subject: Re: FIFO Simulation Oddities!
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 12 Mar 2006 14:01:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 9 Mar 2006 10:09:07 -0800, "simon.stockton@baesystems.com"
<simon.stockton@baesystems.com> wrote:

>
>I have just found out that although in SIMULATION the behaviour of the
>two FIFOs are different in REAL LIFE (on the hardware using CHIPSCOPE
>PRO) both FIFO's behave the same (as per the datasheet, ie. as FIFO A
>is behaving in SIMULATION)

Suspect a difference between the clock signals to each; for example a
simple assignment such as 
fifo_read_clock <= global_clock; 
in one instance but not the other.

The additional delta cycle of "clock skew" can (will) change simulation
behaviour. 

The suggestion of 1ns delay on read enable would hide this clock skew
"problem" and restore normal operation.


- Brian



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