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
U.S. patent law is complex. Simply referring to the U.S. system as "first to invent" rather than "first to file" probably adds more confusion than elucidation to the discussion. Assuming that a U.S. patent application satisfies all the other requirements for a patent, section 102 of the patent code states that a "person shall be entitled to a patent unless ...." Section 102 has six subsections, each giving a different reason that a person should NOT get a patent. Subsections (a), (b), (f) and (g) are most relevant to this discussion. 102(a) blocks the applicant from getting a patent if the invention was publicly known* before the applicant invented it. So if I invented something on July 7, 2003, any publication, public use, etc. before July 7, 2003 should stop me from getting a patent. Note that since I didn't develop the invention before July 7, 2003, there is no way I could have publicly disclosed the invention before July 7, 2003. So there is nothing the inventor can do that will block there patent based on 102(a). 102(b) focuses on the date of the patent application** rather than the date of invention. If my invention was publicly known* more than one year before I applied for the patent, then I should not get a patent. So if I applied for a patent on September 1, 2005, but anyone - including me - publicly disclosed the invention before September 1, 2004, that should block my patent application. 102(f) is easy: "he did not himself invent the subject matter sought to be patented" 102(g) relates to the situation where two different people apply for a patent on the same subject matter; in certain situations an "interference" proceeding may be held. In the interference the person that first applied** for the patent is generally assumed to be the first inventor and entitled to the patent. But if the second person that applied for a patent can prove that he invented first and meets certain other requirements, the second applicant may get the patent rather than the first applicant. * publicly known - is defined somewhat differently for (a) and (b). ** application date is the earlier of the actual application date or the date of the U.S. priority application. A provisional application may provide a priority date; but a document disclosure does not. I hope this clarified more than it confused Richard Tanzer Patent AgentArticle: 93626
Maybe the foillowing from the archive will help: http://www.fpga-faq.org/archives/90900.html#90901 Philip Freidin On 25 Dec 2005 15:47:52 -0800, "Vik" <vdevdas@yahoo.com> wrote: >Hi >I am looking for verilog code for a 64 bit wide datapath. >I used the function generated by EASICS but did not >get the correct results. > >If someone could post the code on how to use the >EASICS function or give me the psedo code or just the steps I need to >perform >to make it work, I would really appreciate it. > >I would also appreciate a sample good packet with the correct CRC >appended to it for verifying the code. > >thanks > >Vikram Philip Freidin FliptronicsArticle: 93627
Hi Brad Are you sure you're decoding Camera Link correctly? Both Channel Link and Camera Link mangle the bit order on the stream, so make sure you'r looking at the correct bit. Avishay Brad Smallridge wrote: > Hello, > > Having trouble with some LVDS signals coming from a Camera Link interface. > I expect to see from steady signals coming from this line camera. DVAL=1. > But it's not there. And the LVAL, line valid, only comes on for maybe one > clock, and I expect it to come on for 2K clocks. > > I am using IBUFDS as inputs. The UCF file loc the pins but that is all. Do > I need something more to drop the 100 ohm termination resitance? > > Brad Smallridge > aivision.comArticle: 93628
<wtxwtx@gmail.com> schrieb im Newsbeitrag news:1135640060.426695.311280@g44g2000cwa.googlegroups.com... > Hi Antti, > I don't have his source code and made a judgement based on the > following warnings: > Unit i2c_tb: 8 multi-source signals are replaced by > logic (pull-up yes): data_bus<0>, data_bus<1>, data_bus<2>, > data_bus<3>, data_bus<4>, data_bus<5>, data_bus<6>, data_bus<7>. > > 1. data_bus are multi-source signals; > 2. data_bus is in the module: i2c_tb. It may be in his test bench code > to make the multi-source error. > > I never claimed that it was the IP code error. Any IP code never makes > such basic and fundamental error. > > Weng > no problems - I just checked the original - form without doing that your guess was 'close' anttiArticle: 93629
Hi Rob, Thanks for the moral support. There is a jumper to make these bank 7 inputs 2.5V instead of 3.3V which I switched. No effect. I ran the inputs into a second camera jack available on my daughter board, to see if I had some solder problems on the first jack. That resulted in the same issues. My scope is old so I am just looking at the tiniest wiggles but again they seem to be OK. In fact I can see the LVAL in the original signal making it wiggle higher than the rest of the signal. Are you using IDELAY to control the timing? Brad "Rob" <robnstef@frontiernet.net> wrote in message news:1Y_rf.430$qg.31@news02.roc.ny... >I know on Altera parts you have to tell the tool to turn on the on-chip >termination resistors: it may be the same with Xilinx. Also, I know on >V2PRO parts the banks running differenital I/O must be operated with a 2.5V >VCCIO. > > Also, I would look at the inputs at the connector to make sure that they > are acting as expected. If you don't have a differential probe you can > get a reasonable look with a single ended one. This is just to make sure > that you're not chasing the wrong problem. > > I've done many designs with Camera Link so let me know if you need > anything else. > > Let us know what you find. > > > "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message > news:11r0jedsghr3me0@corp.supernews.com... >> Hello, >> >> Having trouble with some LVDS signals coming from a Camera Link >> interface. I expect to see from steady signals coming from this line >> camera. DVAL=1. But it's not there. And the LVAL, line valid, only comes >> on for maybe one clock, and I expect it to come on for 2K clocks. >> >> I am using IBUFDS as inputs. The UCF file loc the pins but that is all. >> Do I need something more to drop the 100 ohm termination resitance? >> >> Brad Smallridge >> aivision.com >> >> >> >> > >Article: 93630
"avishay" <avishorp@yahoo.com> wrote in message
news:1135664159.180738.57490@g44g2000cwa.googlegroups.com...
> Hi Brad
> Are you sure you're decoding Camera Link correctly? Both Channel Link
> and Camera Link mangle the bit order on the stream, so make sure you'r
> looking at the correct bit.
>
> Avishay
I hope so. I have a counter and a mux routing all the signals in turn to an
LED that I scope. There is nothing that indicates to me that a DVAL=1 or an
LVAL exist on the X2 stream. I have checked the operation of the camera
with another board that has National LVDS chips and the camera seems to be
operating OK in base configuration, 12 bit, one tap mode.
Channel X0
Bit 0 ChanLink 0 CamLink 0
Bit 1 ChanLink 1 CamLink 1
Bit 2 ChanLink 2 CamLink 2
Bit 3 ChanLink 3 CamLink 3
Bit 4 ChanLink 4 CamLink 4
Bit 5 ChanLink 6 CamLink 5
Bit 6 ChanLink 7 CamLink 8
Channel X1
Bit 0 ChanLink 8 CamLink 9
Bit 1 ChanLink 9 CamLink 10
Bit 2 ChanLink 12 CamLink 11
Bit 3 ChanLink 13
Bit 4 ChanLink 14
Bit 5 ChanLink 15
Bit 6 ChanLink 18
Channel X2
Bit 0 ChanLink 19
Bit 1 ChanLink 20
Bit 2 ChanLink 21
Bit 3 ChanLink 22
Bit 4 ChanLink 24 CamLink LVAL
Bit 5 ChanLink 25
Bit 6 ChanLink 26 CamLink DVAL
Channel X3
Bit 0 ChanLink 27 CamLink 6
Bit 1 ChanLink 5 CamLink 7
Bit 2 ChanLink 10
Bit 3 ChanLink 11
Bit 4 ChanLink 16
Bit 5 ChanLink 17
Bit 6 ChanLink 23
By adding about 50 delay taps to the 140_280 dcm and 4 clock cycles to the
xclk clkdiv signal, I have been able to get a video looking signal,
simultaneously, into all the camlink data positions, except the DVAL and
LVAL. I must admit however that the first and second bits look very similar
on the scope as if they were the same value. All the unmarked signals are
zero.
I have put some of the code below. This is work in progress because I have
begun to play around by fixed IDELAY to the X0 ISERDES. I don't know what is
better, to delay the signals coming into the ISERDESs or delay the clkdiv
strobe.
reset1 <= not sys_rst_in;
cam1_dcmfx: cam1_40_140
port map(
clkin_n_in => cam1_in(6), -- 40 MHz
clkin_p_in => cam1_in(7), -- Differential pair
rst_in => reset1,
clkfx_out => cam1_clk7xdiv2, -- 140MHz
clkin_ibufgds_out => open,
clk0_out => cam1_xclk_0, -- 40 MHz
locked_out => cam1_lock7xdiv2 );
reset_delay_SRL16 : SRL16
generic map (
INIT => X"0000")
port map (
Q => reset2,
A0 => '1', -- 16 clock delays
A1 => '1',
A2 => '1',
A3 => '1',
CLK => cam1_clk7xdiv2,
D => cam1_lock7xdiv2 );
reset3 <= not( cam1_lock7xdiv2 and reset2 );
-- added 20 units of phase delay
cam1_dcm2x: cam1_140_280
port map(
clkin_in => cam1_clk7xdiv2, -- 140 MHz
rst_in => reset3, -- from SRL16
clk0_out => open,
clk2x_out => cam1_clk7x, -- 280 MHz
locked_out => cam1_lock7x );
xclk_delay_process: process(cam1_clk7x)
begin
if( cam1_clk7x'event and cam1_clk7x='1' ) then
cam1_xclk_1 <= cam1_xclk_0;
cam1_xclk_2 <= cam1_xclk_1;
cam1_xclk_3 <= cam1_xclk_2;
cam1_xclk_4 <= cam1_xclk_3;
end if;
end process;
xclk_bufg: BUFG
port map(
O => cam1_xclk,
I => cam1_xclk_4 );
IDELAYCTRL_inst : IDELAYCTRL
port map (
RDY => open, -- 1-bit output indicates validity of the REFCLK
REFCLK => cam1_clk7x, -- 1-bit reference clock input
RST => reset3 ); -- 1-bit reset input
--------------------------------------------------------------------------
-- Camera Link Deserializers
--
-- Each of the four serial streams X0 X1 X2 and X3
-- have a pair of differential inputs _n and _p
-- attached to the gpio_exp_hdr2 (General Purpose Input Output Header 2 )
-- that must be reconciled with an IBUFDS (Input BUFfer Differential Swing)
-- The resulting signal is fed to a pair of Master and Slave
-- ISERDES (Input SERializer DESerializer).
cam1_x0_ibufd_inst : IBUFDS
port map (
O => cam1_x0,
I => cam1_in(1),
IB => cam1_in(0) );
x0_iserdes_master : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- DDR SDR
DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
-- IOBDELAY => "NONE", -- delay chain
"NONE","IBUF","IFD","BOTH"
-- IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT",
"FIXED","VARIABLE"
-- IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63
IOBDELAY => "BOTH", -- delay chain "NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "FIXED", -- tap delay "DEFAULT", "FIXED","VARIABLE"
IOBDELAY_VALUE => 61, -- initial tap delay 0 to 63
NUM_CE => 1, -- clock enables 1,2
SERDES_MODE => "MASTER", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => cam1_x0_bit(0),
Q2 => cam1_x0_bit(1),
Q3 => cam1_x0_bit(2),
Q4 => cam1_x0_bit(3),
Q5 => cam1_x0_bit(4),
Q6 => cam1_x0_bit(5),
SHIFTOUT1 => cam1_x0_shift1,
SHIFTOUT2 => cam1_x0_shift2,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => cam1_clk7x,
CLKDIV => cam1_xclk,
D => cam1_x0,
DLYCE => '0',
DLYINC => '0',
DLYRST => '0',
OCLK => cam1_clk7x,
REV => '0',
SHIFTIN1 => '0',
SHIFTIN2 => '0',
SR => reset3 );
x0_iserdes_slave : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- "DDR" "SDR"
DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
-- IOBDELAY => "NONE", -- delay chain
"NONE","IBUF","IFD","BOTH"
-- IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT",
"FIXED","VARIABLE"
-- IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63
IOBDELAY => "BOTH", -- delay chain "NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "FIXED", -- tap delay "DEFAULT", "FIXED","VARIABLE"
IOBDELAY_VALUE => 61, -- initial tap delay 0 to 63
NUM_CE => 2, -- clock enables 1,2
SERDES_MODE => "SLAVE", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => open,
Q2 => open,
Q3 => cam1_x0_bit(6),
Q4 => open,
Q5 => open,
Q6 => open,
SHIFTOUT1 => open,
SHIFTOUT2 => open,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => cam1_clk7x,
CLKDIV => cam1_xclk,
D => '0',
DLYCE => '0',
DLYINC => '0',
DLYRST => '0',
OCLK => cam1_clk7x,
REV => '0',
SHIFTIN1 => cam1_x0_shift1,
SHIFTIN2 => cam1_x0_shift2,
SR => reset3 );
---------------------------------------------------------------------------
cam1_x1_ibufd_inst : IBUFDS
port map (
O => cam1_x1,
I => cam1_in(3),
IB => cam1_in(2) );
x1_iserdes_master : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- DDR SDR
DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
IOBDELAY => "NONE", -- delay chain "NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT",
"FIXED","VARIABLE"
IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63
NUM_CE => 1, -- clock enables 1,2
SERDES_MODE => "MASTER", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => cam1_x1_bit(0),
Q2 => cam1_x1_bit(1),
Q3 => cam1_x1_bit(2),
Q4 => cam1_x1_bit(3),
Q5 => cam1_x1_bit(4),
Q6 => cam1_x1_bit(5),
SHIFTOUT1 => cam1_x1_shift1,
SHIFTOUT2 => cam1_x1_shift2,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => cam1_clk7x,
CLKDIV => cam1_xclk,
D => cam1_x1,
DLYCE => '0',
DLYINC => '0',
DLYRST => '0',
OCLK => cam1_clk7x,
REV => '0',
SHIFTIN1 => '0',
SHIFTIN2 => '0',
SR => reset3 );
x1_iserdes_slave : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- "DDR" "SDR"
DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
IOBDELAY => "NONE", -- delay chain "NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT",
"FIXED","VARIABLE"
IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63
NUM_CE => 2, -- clock enables 1,2
SERDES_MODE => "SLAVE", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => open,
Q2 => open,
Q3 => cam1_x1_bit(6),
Q4 => open,
Q5 => open,
Q6 => open,
SHIFTOUT1 => open,
SHIFTOUT2 => open,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => cam1_clk7x,
CLKDIV => cam1_xclk,
D => '0',
DLYCE => '0',
DLYINC => '0',
DLYRST => '0',
OCLK => cam1_clk7x,
REV => '0',
SHIFTIN1 => cam1_x1_shift1,
SHIFTIN2 => cam1_x1_shift2,
SR => reset3 );
---------------------------------------------------------------------------
cam1_x2_ibufd_inst : IBUFDS
port map (
O => cam1_x2,
I => cam1_in(5),
IB => cam1_in(4) );
x2_iserdes_master : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- DDR SDR
DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
IOBDELAY => "NONE", -- delay chain "NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT",
"FIXED","VARIABLE"
IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63
NUM_CE => 1, -- clock enables 1,2
SERDES_MODE => "MASTER", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => cam1_x2_bit(0),
Q2 => cam1_x2_bit(1),
Q3 => cam1_x2_bit(2),
Q4 => cam1_x2_bit(3),
Q5 => cam1_x2_bit(4),
Q6 => cam1_x2_bit(5),
SHIFTOUT1 => cam1_x2_shift1,
SHIFTOUT2 => cam1_x2_shift2,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => cam1_clk7x,
CLKDIV => cam1_xclk,
D => cam1_x2,
DLYCE => '0',
DLYINC => '0',
DLYRST => '0',
OCLK => cam1_clk7x,
REV => '0',
SHIFTIN1 => '0',
SHIFTIN2 => '0',
SR => reset3 );
x2_iserdes_slave : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- "DDR" "SDR"
DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
IOBDELAY => "NONE", -- delay chain "NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT",
"FIXED","VARIABLE"
IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63
NUM_CE => 2, -- clock enables 1,2
SERDES_MODE => "SLAVE", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => open,
Q2 => open,
Q3 => cam1_x2_bit(6),
Q4 => open,
Q5 => open,
Q6 => open,
SHIFTOUT1 => open,
SHIFTOUT2 => open,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => cam1_clk7x,
CLKDIV => cam1_xclk,
D => '0',
DLYCE => '0',
DLYINC => '0',
DLYRST => '0',
OCLK => cam1_clk7x,
REV => '0',
SHIFTIN1 => cam1_x2_shift1,
SHIFTIN2 => cam1_x2_shift2,
SR => reset3 );
----------------------------------------------------------------------------
cam1_x3_ibufd_inst : IBUFDS
port map (
O => cam1_x3,
I => cam1_in(9),
IB => cam1_in(8) );
x3_iserdes_master : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- DDR SDR
DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
IOBDELAY => "NONE", -- delay chain "NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT", "FIXED","VARIABLE"
IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63
NUM_CE => 1, -- clock enables 1,2
SERDES_MODE => "MASTER", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => cam1_x3_bit(0),
Q2 => cam1_x3_bit(1),
Q3 => cam1_x3_bit(2),
Q4 => cam1_x3_bit(3),
Q5 => cam1_x3_bit(4),
Q6 => cam1_x3_bit(5),
SHIFTOUT1 => cam1_x3_shift1,
SHIFTOUT2 => cam1_x3_shift2,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => cam1_clk7x,
CLKDIV => cam1_xclk,
D => cam1_x3,
DLYCE => '0',
DLYINC => '0',
DLYRST => '0',
OCLK => cam1_clk7x,
REV => '0',
SHIFTIN1 => '0',
SHIFTIN2 => '0',
SR => reset3 );
x3_iserdes_slave : ISERDES
generic map (
BITSLIP_ENABLE => FALSE, -- TRUE FALSE
DATA_RATE => "SDR", -- "DDR" "SDR"
DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8
INIT_Q1 => '0',
INIT_Q2 => '0',
INIT_Q3 => '0',
INIT_Q4 => '0',
INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING"
IOBDELAY => "NONE", -- delay chain "NONE","IBUF","IFD","BOTH"
IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT",
"FIXED","VARIABLE"
IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63
NUM_CE => 2, -- clock enables 1,2
SERDES_MODE => "SLAVE", -- "MASTER" or "SLAVE"
SRVAL_Q1 => '0',
SRVAL_Q2 => '0',
SRVAL_Q3 => '0',
SRVAL_Q4 => '0')
port map (
O => open,
Q1 => open,
Q2 => open,
Q3 => cam1_x3_bit(6),
Q4 => open,
Q5 => open,
Q6 => open,
SHIFTOUT1 => open,
SHIFTOUT2 => open,
BITSLIP => '0',
CE1 => '1',
CE2 => '1',
CLK => cam1_clk7x,
CLKDIV => cam1_xclk,
D => '0',
DLYCE => '0',
DLYINC => '0',
DLYRST => '0',
OCLK => cam1_clk7x,
REV => '0',
SHIFTIN1 => cam1_x3_shift1,
SHIFTIN2 => cam1_x3_shift2,
SR => reset3 );
cam1_bit( 0) <= cam1_x0_bit(0);
cam1_bit( 1) <= cam1_x0_bit(1);
cam1_bit( 2) <= cam1_x0_bit(2);
cam1_bit( 3) <= cam1_x0_bit(3);
cam1_bit( 4) <= cam1_x0_bit(4);
cam1_bit( 5) <= cam1_x0_bit(5);
cam1_bit( 6) <= cam1_x0_bit(6);
cam1_bit( 7) <= cam1_x1_bit(0);
cam1_bit( 8) <= cam1_x1_bit(1);
cam1_bit( 9) <= cam1_x1_bit(2);
cam1_bit(10) <= cam1_x1_bit(3);
cam1_bit(11) <= cam1_x1_bit(4);
cam1_bit(12) <= cam1_x1_bit(5);
cam1_bit(13) <= cam1_x1_bit(6);
cam1_bit(14) <= cam1_x2_bit(0);
cam1_bit(15) <= cam1_x2_bit(1);
cam1_bit(16) <= cam1_x2_bit(2);
cam1_bit(17) <= cam1_x2_bit(3);
cam1_bit(18) <= cam1_x2_bit(4);
cam1_bit(19) <= cam1_x2_bit(5);
cam1_bit(20) <= cam1_x2_bit(6);
cam1_bit(21) <= cam1_x3_bit(0);
cam1_bit(22) <= cam1_x3_bit(1);
cam1_bit(23) <= cam1_x3_bit(2);
cam1_bit(24) <= cam1_x3_bit(3);
cam1_bit(25) <= cam1_x3_bit(4);
cam1_bit(26) <= cam1_x3_bit(5);
cam1_bit(27) <= cam1_x3_bit(6);
-- Cameral Link is a special subset of the 28 lines above
led_test_counter_3_process:process(cam1_xclk)
begin
if( cam1_xclk'event and cam1_xclk='1') then
if( reset3='1' ) then
test_counter_3 <= (others=>'0');
test_counter_4 <= (others=>'0');
elsif( test_counter_3 = (test_counter_3'range => '1') ) then
test_counter_3 <= (others=>'0');
test_counter_4 <= test_counter_4+1;
else
test_counter_3 <= test_counter_3+1;
end if;
end if;
end process;
led_test0_process:process(cam1_xclk)
begin
if( cam1_xclk'event and cam1_xclk='1') then
if( reset3='1' ) then
gpio(0)<='0';
else
gpio(0)<=test_counter_4( 6);
end if;
end if;
end process;
led_test_counter_5_process:process(cam1_xclk)
begin
if( cam1_xclk'event and cam1_xclk='1') then
if( (test_counter_4(6)='1') and test_5='0' ) then
test_counter_5<= test_counter_5 +1;
elsif( test_counter_5 = 28 ) then
test_counter_5<= (others=>'0');
end if;
test_5 <= test_counter_4(6);
end if;
end process;
led1_out_process:process(test_counter_5)
begin
case test_counter_5 is
when "000000" => gpio(1) <= cam1_bit( 0);
when "000001" => gpio(1) <= cam1_bit( 1);
when "000010" => gpio(1) <= cam1_bit( 2);
when "000011" => gpio(1) <= cam1_bit( 3);
when "000100" => gpio(1) <= cam1_bit( 4);
when "000101" => gpio(1) <= cam1_bit( 5);
when "000110" => gpio(1) <= cam1_bit( 6);
when "000111" => gpio(1) <= cam1_bit( 7);
when "001000" => gpio(1) <= cam1_bit( 8);
when "001001" => gpio(1) <= cam1_bit( 9);
when "001010" => gpio(1) <= cam1_bit(10);
when "001011" => gpio(1) <= cam1_bit(11);
when "001100" => gpio(1) <= cam1_bit(12);
when "001101" => gpio(1) <= cam1_bit(13);
when "001110" => gpio(1) <= cam1_bit(14);
when "001111" => gpio(1) <= cam1_bit(15);
when "010000" => gpio(1) <= cam1_bit(16);
when "010001" => gpio(1) <= cam1_bit(17);
when "010010" => gpio(1) <= cam1_bit(18);
when "010011" => gpio(1) <= cam1_bit(19);
when "010100" => gpio(1) <= cam1_bit(20);
when "010101" => gpio(1) <= cam1_bit(21);
when "010110" => gpio(1) <= cam1_bit(22);
when "010111" => gpio(1) <= cam1_bit(23);
when "011000" => gpio(1) <= cam1_bit(24);
when "011001" => gpio(1) <= cam1_bit(25);
when "011010" => gpio(1) <= cam1_bit(26);
when "011011" => gpio(1) <= cam1_bit(27);
when others => gpio(1) <= '1';
end case;
end process;
gpio(2) <= cam1_bit(0);
gpio(3) <= cam1_bit(1);
> Brad Smallridge wrote:
>> Hello,
>>
>> Having trouble with some LVDS signals coming from a Camera Link
>> interface.
>> I expect to see from steady signals coming from this line camera. DVAL=1.
>> But it's not there. And the LVAL, line valid, only comes on for maybe one
>> clock, and I expect it to come on for 2K clocks.
>>
>> I am using IBUFDS as inputs. The UCF file loc the pins but that is all.
>> Do
>> I need something more to drop the 100 ohm termination resitance?
>>
>> Brad Smallridge
>> aivision.com
>
Article: 93631Well, I've a XPS project with a MicroBlaze and BRAMs on the hardware side, and a C program on the software side. I'm able to synthesize it (with synplify for example), and put this submodule as netlist in a EDK pcore. Then I can use it as "peripheral" for another XPS project, which describes my complete system (with PPC and so...). But I've a problem. How to initialize Microblaze's BRAM without generating the bitstream of my submodule ? I've seen a commercial Core with a microblaze inside. They give the memory .bmm with it, to be able to update the software. I've tried to "init_bram" after the bitstream generation from the main xps project. But it seems that this bmm file, without the "par" informations is useless. Thanks in advance. Best regards.Article: 93632
"Cédric Jeanneret" <cedric.jeanneret@epfl.ch> schrieb im Newsbeitrag news:43b10e7c$1@epflnews.epfl.ch... > Well, > > I've a XPS project with a MicroBlaze and BRAMs on the hardware side, and > a C program on the software side. I'm able to synthesize it (with > synplify for example), and put this submodule as netlist in a EDK pcore. > > Then I can use it as "peripheral" for another XPS project, which > describes my complete system (with PPC and so...). > > But I've a problem. How to initialize Microblaze's BRAM without > generating the bitstream of my submodule ? > > I've seen a commercial Core with a microblaze inside. They give the > memory .bmm with it, to be able to update the software. I've tried to > "init_bram" after the bitstream generation from the main xps project. But > it seems that this bmm file, without the "par" informations is useless. > > Thanks in advance. > > Best regards. > > correct. you can update existing .BIT with the SW only if you have the proper .BMM with the location information in it, otherwise its no use AnttiArticle: 93633
"Frank Schreiber" <frankschr@googlemail.com> schrieb im Newsbeitrag news:dopoa5$mlo$1@anderson.hrz.tu-chemnitz.de... > Hello > I am starting FPGA with a V4MB, without any download cable, but a RS-232 > cable. I am wondering how to download my bit stream file to my board. > Could anyone help me ? > Frank > > there are almost no boards that can be configured over RS232 and not so many that can over USB 1 digilent XUP board - Platform USB Cable embedded on board 2 digilent Spartan 3E starterkit - Platform USB Cable embedded on board 3 Cesys USB boards custom USB downloader 4 Avnet S3e100 eval board custom USB downloader 5 Avnet Virtex 4 boards, USB downloader DISABLED by board assembly option 6 www.fpga4fun.com custom USB downloader 7 opalkelly custom USB downloader 8 ??? to my knowledge there are no V4 boards with onboard rs232/usb configuration (unless you have scuh board ?) so the only help for you is to get an JTAG cable AnttiArticle: 93634
Hi Richard, Thank you for your excellent advice. After reading this post, I finally understand what you have said in your previous several postings. WengArticle: 93635
Hi can anyone share a EDK wrap for the DDR2 IP-Core? It is scheduled for upcoming EDK releases but maybe someone has internal version of the PLB-DDR2 wrap for MIG DDR2 core? We have a board to bring up and I do not like the idea of re-inventing something that is already done. AnttiArticle: 93636
Binary wrote: > Hi all, > > I wander how to find the IEEE package VHDL reference manual in > Internet, can you pls give me a link? There are a lot of IEEE packages. Did you mean 1164? Here's a quick reference guide for 1164. http://www.eda.org/rassp/vhdl/guidelines/1164qrc.pdf Regards, AllanArticle: 93637
Cédric Jeanneret <cedric.jeanneret@epfl.ch> writes:
> But I've a problem. How to initialize Microblaze's BRAM without
> generating the bitstream of my submodule ?
You can do this with the "bitinit" program. Here's an extract from the
makefile I've made for this purpose (under Linux with PPC rather than
MB):
$(CHIP)-fpga-ppc.bit: $(CHIP)-fpga.bit ../system/TestApp/executable.elf
bitinit ../system/system.mhs -bm ../system/implementation/system_stub_bd.bmm \
-pe ppc405_0 ../system/TestApp/executable.elf -bt $< -o $@
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Article: 93638Here's how I've done it in the past. data2mem can generate a ucf file which can then be used by ngcbuild to add the elf info directly to the subproject netlist. This augmented netlist will then be passed through the rest of the implementation flow resulting in the BRAMs being properly programmed in the final bit file. Note that http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/dev/dev0203_29.html indicates that this is a "legacy" data2mem option. Not sure how I'd do it if xilinx removes this option. Hope this helps. Paul Cédric Jeanneret wrote: > > Well, > > I've a XPS project with a MicroBlaze and BRAMs on the hardware side, and > a C program on the software side. I'm able to synthesize it (with > synplify for example), and put this submodule as netlist in a EDK pcore. > > Then I can use it as "peripheral" for another XPS project, which > describes my complete system (with PPC and so...). > > But I've a problem. How to initialize Microblaze's BRAM without > generating the bitstream of my submodule ? > > I've seen a commercial Core with a microblaze inside. They give the > memory .bmm with it, to be able to update the software. I've tried to > "init_bram" after the bitstream generation from the main xps project. > But it seems that this bmm file, without the "par" informations is useless. > > Thanks in advance. > > Best regards.Article: 93639
> there are almost no boards that can be configured over RS232 > > and not so many that can over USB > > 1 digilent XUP board - Platform USB Cable embedded on board > 2 digilent Spartan 3E starterkit - Platform USB Cable embedded on board > 3 Cesys USB boards custom USB downloader > 4 Avnet S3e100 eval board custom USB downloader > 5 Avnet Virtex 4 boards, USB downloader DISABLED by board assembly option > 6 www.fpga4fun.com custom USB downloader > 7 opalkelly custom USB downloader > 8 ??? The dspio extension for a Cyclone board: http://www.soc.tuwien.ac.at/courses/projects/dspio It uses the FTDI2232 chip. The board is open-source and a small C program for configuration is available from the website. Could be a starting point when you want to make your own USB download cable. MartinArticle: 93640
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag news:43b15c03$0$12126$3b214f66@tunews.univie.ac.at... >> there are almost no boards that can be configured over RS232 >> >> and not so many that can over USB >> >> 1 digilent XUP board - Platform USB Cable embedded on board >> 2 digilent Spartan 3E starterkit - Platform USB Cable embedded on board >> 3 Cesys USB boards custom USB downloader >> 4 Avnet S3e100 eval board custom USB downloader >> 5 Avnet Virtex 4 boards, USB downloader DISABLED by board assembly option >> 6 www.fpga4fun.com custom USB downloader >> 7 opalkelly custom USB downloader > > >> 8 ??? > The dspio extension for a Cyclone board: > http://www.soc.tuwien.ac.at/courses/projects/dspio > > It uses the FTDI2232 chip. The board is open-source and > a small C program for configuration is available from the > website. Could be a starting point when you want to make > your own USB download cable. > > Martin > > hi Martin, last time I checked the dspio the usb loader was not available now it is - so that another USB config enable solution too bad the dspio PCB is not available for purchase :( I actually would like some PCB with FT2232 and AC97 on it so the dspio board would be ok, but hence it is not available I need to look other solutions AnttiArticle: 93641
A friend send me a document link. http://direct.xilinx.com/bvdocs/notifications/xcn05025.pdf He suggest we do not select Virtex4 in our projects. I am not sure the real meaning of this document. Does it mean that there are three bugs in the step 1 Virtex4 LX/SX? Why do not call the Step 2 LX/SX as the mass production LX/SX? Are there still bugs in step 2 LX/SX? Whether step 3 LX/SX will be relased later? Why FX is in step 0 now, what's the defination of step 0? Please help me! If it is ture, I would like to use the old VirtexII or Stratix on my projects. Thanks, EngineArticle: 93642
Engine wrote: > A friend send me a document link. > http://direct.xilinx.com/bvdocs/notifications/xcn05025.pdf > > He suggest we do not select Virtex4 in our projects. > > I am not sure the real meaning of this document. > > Does it mean that there are three bugs in the step 1 Virtex4 LX/SX? > Why do not call the Step 2 LX/SX as the mass production LX/SX? > Are there still bugs in step 2 LX/SX? > Whether step 3 LX/SX will be relased later? > Why FX is in step 0 now, what's the defination of step 0? > > Please help me! > > If it is ture, I would like to use the old VirtexII or Stratix on my > projects. > > Thanks, > Engine > > > > > Think of the stepping number as service packs for the silicon. The higher stepping numbers generally reflect silicon revisions to correct deficiencies in earlier silicon. There aren't really any show-stopper bugs in the V4 silicon, so I wouldn't discard a V4 solution jsut because someone suggested you didn't use the parts. Step 0 is the first silicon, which is/was sold as the engineering samples. The NBTI problem mentioned in the link you posted turns out to be a non-problem for real world designs. It does degrade DCM performance if the DCMs are not operated according to the constraints listed, but the DCM is so much faster than what is required to support the fabric, that the degradation does not slow them enough to affect real-world designs. IMHO, Xilinx did the right thing with regards to disseminating info about the NBTI problem so that customers could work with all the info known at the time rather than leaving the customer to potentially discovering a problem on their own later (unlike the handling of the FIFO16 issue). The Virtex4 does have significant advantages over the earlier families. As with most silicon rollouts of this complexity, there are some fairly minor bugs in the design that will be worked out over time. The only one I am aware of that is a show stopper is the MGT's in the FX line. If that doesn't affect your design plans, there is no reason I can see to avoid the V4 line. I've got a couple major V4SX55 designs working satisfactorly in the lab now, and overall I am happy with the device.Article: 93643
Engine, Well, we did not invent stepping, Intel did. Stepping is just another way to keep track of what you are shipping. Let me give you an example: We go to production, even perhaps with errata: http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14052 which is an example of an errata for Virtex 2 Pro. Errata are items that are presently not working as they are described in the documentation. Errata can be cleared by: manual work-arounds with technical answers, or product notices; changes to the silicon (very rare); changes to the software (so that the problem is worked around automatically; and everything works as documented); or changes to the data sheet (so that the issue is described properly). The stepping system ensures "backward compatibility" which means that any future chips MUST work with older bitstreams, in older designs. This means that the customer does not have to worry that a new mask revision will cause all of your previous IP to suddenly be "broken" and need to be regenerated! Some other manufacturers are on their n-th revision of silicon, and have no "stepping" system at all, nor any policy about what they are doing (to you). If anything, I would require a properly documented stepping policy for approval of any component, so that I would be sure that I would not be "surprised" in any future shipment. To this end, Virtex 4 was one of the first products to have the fully implemented stepping system in place. Eventually all products will use the system. As always, if your company has its own policies, with their own requirements, Xilinx is more than willing to work with you to establish your own required flow to meet those needs. Some examples are customers who require samples of the new stepping, and need 90 days before the new stepping is allowed to be shipped to them as production. These requirements are quite common with automotive suppliers, for example. If you have any other concerns or questions on stepping, please consult your Xilinx FAE. As well, if you have any questions or concerns about errata, also consult your FAE. Austin Engine wrote: > A friend send me a document link. > http://direct.xilinx.com/bvdocs/notifications/xcn05025.pdf > > He suggest we do not select Virtex4 in our projects. > > I am not sure the real meaning of this document. > > Does it mean that there are three bugs in the step 1 Virtex4 LX/SX? > Why do not call the Step 2 LX/SX as the mass production LX/SX? > Are there still bugs in step 2 LX/SX? > Whether step 3 LX/SX will be relased later? > Why FX is in step 0 now, what's the defination of step 0? > > Please help me! > > If it is ture, I would like to use the old VirtexII or Stratix on my > projects. > > Thanks, > Engine > > > > >Article: 93644
"Antti Lukats" <antti@openchip.org> schrieb im Newsbeitrag news:dorp4a$1da$1@online.de... > "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag news:43b15c03$0$12126$3b214f66@tunews.univie.ac.at... >>> there are almost no boards that can be configured over RS232 >>> >>> and not so many that can over USB >>> >>> 1 digilent XUP board - Platform USB Cable embedded on board >>> 2 digilent Spartan 3E starterkit - Platform USB Cable embedded on board >>> 3 Cesys USB boards custom USB downloader >>> 4 Avnet S3e100 eval board custom USB downloader >>> 5 Avnet Virtex 4 boards, USB downloader DISABLED by board assembly option >>> 6 www.fpga4fun.com custom USB downloader >>> 7 opalkelly custom USB downloader >> >> >>> 8 ??? >> The dspio extension for a Cyclone board: >> http://www.soc.tuwien.ac.at/courses/projects/dspio >> >> It uses the FTDI2232 chip. The board is open-source and >> a small C program for configuration is available from the >> website. Could be a starting point when you want to make >> your own USB download cable. >> >> Martin >> >> > hi Martin, > > last time I checked the dspio the usb loader was not available > now it is - so that another USB config enable solution > > too bad the dspio PCB is not available for purchase :( > I actually would like some PCB with FT2232 and AC97 on it > so the dspio board would be ok, but hence it is not available > I need to look other solutions > > Antti Hi Antti, I have produced several of them at the university. I can arrange it that the University will sell you one. The price is about EUR 100,- MartinArticle: 93645
Does anyone know of a testbench for driving the Opencores USB 2.0 function core? I'm starting to play with the core and I'd haate to duplicate any work that's already been done. Thanks! John ProvidenzaArticle: 93646
"johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag news:1135703787.884273.241050@g47g2000cwa.googlegroups.com... > Does anyone know of a testbench for driving the Opencores USB 2.0 > function core? > > I'm starting to play with the core and I'd haate to duplicate any work > that's already been done. > > > Thanks! > > John Providenza > no, there is not, and most likely will not be. the usb 2.0 core at opencores has several bugs and is not directly useable. AnttiArticle: 93647
marco wrote:
> Does anyone know where I can find information about the place and
> route algorithms used for FPGAs
Globally optimal placement and routing is an NP-hard problem even for
multilayer PCBs, so all you can expect is only a set of approximations, if
you want to receive that placement in a reasonable time.
Best regards
Piotr Wyderski
--
"If you were plowing a field, which would you rather use?
Two strong oxen or 1024 chickens?" -- Seymour Cray
Article: 93648AMD received the transistor diagrams as part of the second-source agreement, and they then reverse-engineered a logic diagram. (I know, for I was involved). AMD is a bigger, and perhaps more organized company. But this is all some 27 years ago... Peter Alfke ============= Monte Dalrymple wrote: > > > >> Oh, the documentation existed, and it was in the control of Shima, the > designer. But once he left the company I don't know who, if anyone, > inherited his filing cabinet. It wasn't until much later that such design > materials were kept in a centralized location with a control number > and access/revision control. Even then, sometimes things went in to > DC never to be found again, so designers hated to give the original > stuff up to DC. > > MonteArticle: 93649
I seem to have missed some articles in this thread, as there are some things being reference that I can't having seen. However, I would like to respond to some of the last comments I've seen. Reza Naima wrote: > It seems my biggest problem was that I though that HDL would give me > the ability to write behavioral code and the software would be able > to make it work... Yes, that is always the hitch--in every area where we have automated tools: synthesizers, parser generators (my area of expertise), 4GL lanugages, natural language translators, et al. There is some level of behavioral code that tools will be able translate. However, they will never reach the "holy grail". This is no "dwim" (do what I mean) instruction and cannot be. What we have are idioms that tools can understand and paraphrase. If you learn the idioms (dialect) the tool can speak, you can make it do quite a bit. Here is some very specific advice about what idioms that synthesizers understand. Jan Decaluwe wrote: > My advice: for implementation-oriented modeling, you only need 2 > templates: the synchronous always block (sensitive to a clock > edge and possibly a reset edge), and the combinatorial always > block (sensitive to the input signal levels). This is the essence of a digital design course. Laying down combinatorial logic that is fed into (or driven by) a set of flip-flops that are clocked at an appropriate time. At some very deep level all synchronous digital design is about designing an FSM (finite state machine) which is merely a collection of gates around flip-flops. J> To a large extent, you can concentrate on getting the behavior > right (hard enough), and rely on the synthesis tool to give you a good > implementation. This is true. If you build everything, out of the two blocks described, you will have designed a circuit that a synthesizer can build. There are still timing issues and other things to worry about. However, the synthesizer will be able to lay down a set of gates that does what your model does. This is the technology that the syntehsizer writers' have, a way of translating those two idioms into circuitry. Those are probably about the only two universal idioms, because they represent things that are present in all forms (implementations) of Boolean logic. Things like tri-state drivers are not universal, because they are not purely parts of Boolean logic and some implementations will have them and others may not. Moreover, they may work "differently" in varying implementations, because the underlying mechanism may work "differently", and that may require specifying them differently at the source level, to give a better interpretation of the semantics of the implementation. J> In contrast to what many people will tell you (and sometimes shout > at you), there's no need to try to visualize the exact hardware that > will come out. Believe me, they can't either. Here I will disagree to some extent. Jan is correct in that I can't predict exactly what gates will be infered by a synchronous always block I write. However, I do have a reasonable expectation, that it will be some combinatorial logic feeding some flip-flops and some combinatorial logic leading away from the flip-flops. Moreover, when I've written a synchronous always block, I have a pretty code idea what signal is going to be driving the clock pins of the flip-flops in that block. Now, if I want something different, say a tri-state bus with some keeper that has a specific decay on it, I will write different Verilog code. I will be really surprised if a synthesizer writes out a tri-state bus when I've written a synchronous always block--the synchronous always block is not the idiom used to create a tri-state bus. This is what I mean, by think hardware. Learn the idioms and what they translate to. There aren't many of them. I think I know about 5: combinatorial code, synchronous (clocked) always block, tri-state driver, priority encoder, and mux. Once you've learned the idioms, then you know when you want something that works like x, you pick the idiom that generates an x. Now, you may not know all the hardware the synthesizer will generate to lay down an x (and the synthesizer may even be more clever than you are and know that a y will work in the given context and substitute a y), but you'll have basic concepts of what the synthesizer can do for you and you will design circuits which the synthesizer can lay down. When I want to design something, I think how I can build it using those basic concepts, and once I know that I can build it out of those things, then I have a rough design. If I want something that I can't map to those concepts, then I don't know how to build it (and I don't know what to tell the synthesizer either). Not to beat a dead horse, but I have one final comment on the topic of "thinking in hardware". It has to do with for-loops. There are some for loops that can be synthesized, but many (most) cannot. In general for-loops that search cannot by synthesized. Nor can ones that do sorting. For-loops that simply iterate over each bit of a resigter can. If one lays down an unsynthesizable for-loop in an otherwise synthesizable always block, the result is unsynthesizable. The whole point of "thinking in terms of hardware" is avoiding writing that kind of code. Finally, I don't have a good answer to: R> - There have been several replies indicating that the order of the > statment has to do with priorities, and an async reset has a higher > priority. Why is this? Is this just how flipflops are physically > built? It's probably more likely an artifact of the synthesizer. As I said previoiusly, the synthesizer works by matching your code to its templates. Those templates have some assumptions built into them. Now, there are some variations in the templates the synthesizer can handle (and better synthesizers generally can handle more variation). However, at some level, when you've strayed too far from the templates, the synthesizer writer cannot legitimately infer what you "meant" and the writer chooses instead to give you an error telling you to change your code into something that better matches the templates (rather than instantiating something that is wrong). Hope this helps, -Chris ***************************************************************************** Chris Clark Internet : compres@world.std.com Compiler Resources, Inc. Web Site : http://world.std.com/~compres 23 Bailey Rd voice : (508) 435-5016 Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours) ------------------------------------------------------------------------------
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