Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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. AllanArticle: 98501
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"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. MarcoArticle: 98503
"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 AnttiArticle: 98504
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 meArticle: 98505
nice accident ! at least we know that number 5 isnt skipped in the Virtex roadmap ;) AnttiArticle: 98506
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 HendraArticle: 98507
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: 98508Thomas 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. JohnArticle: 98509
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
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. AustinArticle: 98511
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"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 AnttiArticle: 98513
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. -- ParagArticle: 98514
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: 98515I 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! /MikhailArticle: 98516
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> 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
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
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 SulimmaArticle: 98520
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
"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
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. EricArticle: 98523
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: 98524On 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:
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