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
Hello,
in my design I'm using an Array "temp" and want it to by inferred as
BlockRAM. But the xst (9.1) only implements it on distibuted RAM:
INFO:Xst:2664 - HDL ADVISOR - Unit <lsp_to_lpc> : The RAM <Mram_temp>
will be implemented on LUTs either because you have described an
asynchronous read or because of currently u
nsupported block RAM features. If you have described an asynchronous
read, making it synchronous would allow you to take advantage of
available block RAM resources, for optimized device usage and improved
timings. Please refer to your documentation for coding guidelines.
-----------------------------------------------------------------------
| ram_type | Distributed |
|
-----------------------------------------------------------------------
| Port A
|
| aspect ratio | 22-word x 32-bit |
|
| clkA | connected to signal <CLOCK> | rise
|
| weA | connected to signal <Mram_lpc_not0000> |
high |
| addrA | connected to signal <temp_idx1> |
|
| diA | connected to internal node |
|
| doA | connected to internal node |
|
-----------------------------------------------------------------------
| Port B
|
| aspect ratio | 22-word x 32-bit |
|
| addrB | connected to signal <temp_idx2> |
|
| doB | connected to internal node |
|
-----------------------------------------------------------------------
I've looked through my design, but I can't find any asynchronous read?
Can anybody please take a look at this?
architecture behav of lsp_to_lpc is
type STATE_TYPE is (WAITING, PART1, PART1_2, PART2, PART3, PART3_1,
PART3_2, PART3_3, PART3_4, PART4, PART5, PART6, PART7, PART7_1,
WRITE_OUT);
signal STATE : STATE_TYPE;
type memory_20B is array (0 to 9) of signed (15 downto 0);
signal lpc : memory_20B;
type memory_17_5B is array (0 to 9) of signed (13 downto 0);
signal lsp : memory_17_5B;
signal lsp_idx, lsp_idx2, lpc_idx : integer range 0 to 9;
type memory_88B is array (0 to 21) of signed (31 downto 0);
signal temp : memory_88B;
signal temp_idx1, temp_idx2 : integer range 0 to 21;
signal xout1, xout2, xin1, xin2 : signed (31 downto 0);
signal i : integer range 0 to 20;
signal j : integer range 0 to 11;
signal started : std_logic;
signal tmp_a, tmp_b : signed (31 downto 0);
begin
main : process (CLOCK, RESET)
variable temp_a, temp_b : signed (31 downto 0);
begin
if (RESET = '1') then
STATE <= WAITING;
i <= 0;
j <= 0;
DATA_OUT <= (others => '0');
DONE <= '0';
started <= '0';
READY <= '1';
xout1 <= (others => '0');
xout2 <= (others => '0');
xin1 <= (others => '0');
xin2 <= (others => '0');
lsp_idx <= 0;
lsp_idx2 <= 0;
lpc_idx <= 0;
temp_idx1 <= 0;
temp_idx2 <= 10;
tmp_a <= (others => '0');
tmp_b <= (others => '0');
elsif (CLOCK'event and CLOCK = '1') then
case STATE is
when WAITING =>
DONE <= '0';
if (START = '1' or started = '1') then
if (i < 10) then
READY <= '0';
lsp(lsp_idx) <= ANGLE2X(DATA_IN)(15 downto 2);
lpc(lpc_idx) <= (others => '0');
temp(temp_idx1) <= (others => '0');
if (i < 9) then
lsp_idx <= lsp_idx + 1;
lpc_idx <= lpc_idx + 1;
end if;
temp_idx1 <= temp_idx1 + 1;
i <= i + 1;
started <= '1';
else
xout1 <= (others => '0');
xout2 <= (others => '0');
started <= '0';
i <= 0;
STATE <= PART1;
xin1 <= "00000000000100000000000000000000";
xin2 <= "00000000000100000000000000000000";
end if;
end if;
when PART1 =>
if (temp_idx1 < 21) then
temp(temp_idx1) <= (others => '0');
temp_idx1 <= temp_idx1 + 1;
else
temp(temp_idx1) <= (others => '0');
temp_idx1 <= 0;
STATE <= PART1_2;
end if;
when PART1_2 =>
if (j <= 10) then
STATE <= PART2;
else
STATE <= WRITE_OUT;
DONE <= '1';
lpc_idx <= 0;
j <= 0;
end if;
when PART2 =>
if (i < 20) then
lsp_idx <= i/2;
lsp_idx2 <= i/2 + 1;
temp_idx1 <= i;
temp_idx2 <= i + 2;
STATE <= PART3;
else
temp_idx1 <= 20;
temp_idx2 <= 21;
STATE <= PART5;
i <= 0;
end if;
when PART3 =>
tmp_a <= temp(temp_idx1); -- temp(i)
tmp_b <= temp(temp_idx2); -- temp(i + 2)
temp_idx1 <= i;
STATE <= PART3_1;
when PART3_1 =>
xout1 <= xin1 - MULT16_32_Q14(lsp(lsp_idx) & "00", tmp_a);
xout2 <= xin2 - MULT16_32_Q14(lsp(lsp_idx2) & "00", tmp_b);
temp(temp_idx1) <= xin1; -- temp(i)
temp_idx1 <= i + 1;
temp_idx2 <= i + 3;
STATE <= PART3_2;
when PART3_2 =>
xout1 <= xout1 + temp(temp_idx1); -- temp(i + 1)
xout2 <= xout2 + temp(temp_idx2); -- temp(i + 3)
temp_idx1 <= i + 1;
STATE <= PART3_3;
when PART3_3 =>
temp(temp_idx1) <= tmp_a; -- temp(i + 1)
temp_idx1 <= temp_idx1 + 1;
STATE <= PART3_4;
when PART3_4 =>
temp(temp_idx1) <= xin2; -- temp(i + 2)
temp_idx1 <= temp_idx1 + 1;
STATE <= PART4;
when PART4 =>
temp(temp_idx1) <= tmp_b; -- temp(i + 3)
xin1 <= xout1;
xin2 <= xout2;
i <= i + 4;
STATE <= PART2;
when PART5 =>
xout1 <= xin1 + temp(temp_idx1);
xout2 <= xin2 - temp(temp_idx2);
if (j > 0) then
STATE <= PART6;
lpc_idx <= j - 1;
else
STATE <= PART7;
end if;
when PART6 =>
if (xout1 + xout2 > 8388096) then
lpc(lpc_idx) <= "0111111111111111";
elsif (xout1 + xout2 < -8388096) then
lpc(lpc_idx) <= "1000000000000001";
else
lpc(lpc_idx) <= CUT(shift_right(xout1 + xout2 +
"00000000000000000000000010000000", 8));
end if;
STATE <= PART7;
when PART7 =>
temp(temp_idx1) <= xin1;
temp_idx1 <= temp_idx1 + 1;
STATE <= PART7_1;
when PART7_1 =>
temp(temp_idx1) <= xin2;
xin1 <= (others => '0');
xin2 <= (others => '0');
j <= j + 1;
STATE <= PART1_2;
when WRITE_OUT =>
if (i < 10) then
DATA_OUT <= lpc(lpc_idx);
if (i < 9) then
lpc_idx <= lpc_idx + 1;
end if;
i <= i + 1;
else
i <= 0;
lpc_idx <= 0;
lsp_idx <= 0;
temp_idx1 <= 0;
temp_idx2 <= 10;
STATE <= WAITING;
READY <= '1';
end if;
end case;
end if;
end process main;
end behav;
Article: 114601James wrote: "Thanks guys, I keep forgetting what the FPGA actually does." I used to get confused, too. So I made a mental picture of a PLD (CPLD or FPGA) as a board full of digital logic chips (gates and flip-flops, but _no_ one-shots!). An HDL (VHDL or Verilog), in effect, describes how those chips are wired. With these two things in mind, I usually avoid the newbie pitfalls. BTW, I recently bought a great VHDL book "RTL Hardware Design Using VHDL". It teaches RTL design and VHDL, and assumes you know what AND, OR, and NOT gates are. It has lots of examples. I think I got it @ Amazon. HTH -Dave PollumArticle: 114602
axalay wrote: > XOR - is not detrct + or - phase shift. And I not use external phase > detect chips. I whant do it in FPGA. And structure of phase detector > from XAPP028 is not work! > > Vasiliy Vasiliy, It works just fine, although the timing tools will give you grief over the combinatorial feedback loop, and simulators may choke on it. You might double check that your PU/PD are pumping in the right direction, and that your external analog filter is correct. An altermative implementation uses a pair of FFs, one clocked high by your feedback clock, one clocked high by the reference clock, and both asynchronously reset when both are high. PU and PD are decoded when one or the other FF is high. Slightly more simulator friendly. Just JohnArticle: 114603
Check also the configuration pins... I believe one of htem can cause a manual reconfiguration of hte FPGA. Make it is tied high properly, and check the voltage on it with a scope to see if it gets pulled low. Gabor wrote: > Dennis Yurichev wrote: > > Hi. > > Sorry, I'm newbie here. > > What can cause such problem: after configuring device, it's working for > > about few seconds, and then rebooting (reconfiguring itselfs). > > Quartus 6.1 showed the only problems present in some clock hold paths. > > Design uploaded via JTAG. > > Generally, what conditions may reason automatic rebooting? I didn't > > find that in official manuals. > > Generally the first thing to check is the power supplies. Chips > can reboot if there is a droop in the voltage. This often happens > when the design has lots of switching nodes that cause a sudden > increase in Idd. If your decoupling cannot supply the excess > current the voltage can drop to the internal reset trip point.Article: 114604
Thanks for these relevant responses. How would i make a "diff" between Sparc V7 & V8 ??? "Uncle Noah" <nkavv@skiathos.physics.auth.gr> wrote in message news:1169295286.675725.48610@51g2000cwl.googlegroups.com... > >> > Does anybody know if a SYNTHETISABLE Sparc V7 IP core is available ? >> > I got the ERC32 free core which is useful for simulation but not >> > synthetisable. >> > >> >> Why don't you just disable the integer multiply/divide in Leon to get >> back >> to a V7 version, I don't believe you will find anything as good, powerful >> and free as the Leon core. > > I agree with that. Your best chance is to downscale an existing LEON > (or LEON2) processor core. I recall a published technique discussing > "specializing" processors by removing features from more general ones > mainly for targeting lower area and power consumption. It is called > "instruction subsetting" i think. > > Nikolaos Kavvadias >Article: 114605
"geschma" <geschma@hotmail.com> wrote in message news:1169304277.348484.175640@v45g2000cwv.googlegroups.com... > Hello, > > in my design I'm using an Array "temp" and want it to by inferred as > BlockRAM. But the xst (9.1) only implements it on distibuted RAM: > > INFO:Xst:2664 - HDL ADVISOR - Unit <lsp_to_lpc> : The RAM <Mram_temp> > will be implemented on LUTs either because you have described an > asynchronous read or because of currently u > nsupported block RAM features. If you have described an asynchronous > read, making it synchronous would allow you to take advantage of > available block RAM resources, for optimized device usage and improved > timings. Please refer to your documentation for coding guidelines. > > ----------------------------------------------------------------------- > | ram_type | Distributed | > | > > ----------------------------------------------------------------------- > | Port A > | > | aspect ratio | 22-word x 32-bit | > | > | clkA | connected to signal <CLOCK> | rise > | > | weA | connected to signal <Mram_lpc_not0000> | > high | > | addrA | connected to signal <temp_idx1> | > | > | diA | connected to internal node | > | > | doA | connected to internal node | > | > > ----------------------------------------------------------------------- > | Port B > | > | aspect ratio | 22-word x 32-bit | > | > | addrB | connected to signal <temp_idx2> | > | > | doB | connected to internal node | > | > > ----------------------------------------------------------------------- > > I've looked through my design, but I can't find any asynchronous read? > Can anybody please take a look at this? > [unformatted code snipped] Your code would be a lot easier to read if you indented it. If you have a synchronous read, the doB becomes valid on a rising clock. The register which supplies the address must have been latched on a previous clock. The output data cannot be latched until the *next* clock. So, when you write code like this: tmp_b <= temp(temp_idx2); Let's say temp_idx2 was latched at time t=0; if we do a synchronous read, doB is not valid until after t=1; and tmp_b must be latched at t=2. Your code implies an asynchronous read, because you're latching tmp_b at t=1.Article: 114606
Thanks so much for your reply, Paul. Here I add some information: > #1 - Why is one signal rising at 10264ns, and the other at 10263ns? As I told before, i just can't figure out why there are differences in the the timming of the signals. What puzzles me the most is that even the signal SHIFTWR (which is generated by the testbench and has nothing to do with the synthesized netlist whatsoever) changes its timming, presenting its rising edge @ 8463ns and @ 8487ns, respectively. Clearly this is unexpected behavior. I have no clue of what could be the reason nor how to trace it back... > #2 - Who wrote the relevant simulation models? Is there a race in them? Please excuse me for not been that proficient... I don't understand what do you mean by "race". But I can assure you that the **very same** testbech is being used in both cases. > #3 - Why are you set at 1ns resolution? Is this a *very* slow chip? I > bet your sim models are set to 1ps; I'd suspect a rounding problem somewhere. We also think the problem might have to do with this. I just set the resolution to 1ns because that is the value of the resolution of the SDF files, but I have experimented by changing this value and the timing of the waveform changes A LOT. However, I haven't been able to make the simulation give the expected results by tweaking this parameter. The operating frequency of the design is 50MHz. > #4 - What do you get if you enable sdf warnings & errors? In 5.8b I get a lot (nearly 50,000) of the following warnings: # ** Warning: (vsim-SDF-3262) ./DFM_TC_Worst.pt.sdf(<-SDF line number here->): Failed to find matching specify timing constraint. ... but the simulation works. On the other hand, in 6.2e, I get this same error but a lot more times (something like three times more), I additionally I get the following error (once again, I get it a lot of times): # ** Warning: (vsim-SDF-3261) ./DFM_TC_Worst.pt.sdf(<-SDF line number here->): Failed to find matching specify module path. I used the VERR command in the hope of finding an explanation for this errors, but the descriptions of the errors give me no clue of what could be their real cause. THANKS A LOT ONCE AGAIN FOR YOUR HELP!!!Article: 114607
Go to http://www.dilloneng.com/documents/howto/inferring-block-ram-and-distributed-ram-in-xst-and-precision/view for a short, but to the point tutorial about how to infer block vs. distributed ram in XST. The error message appears to be a red herring in this case. From a quick glance at your code, it seems that your problem is not registering the address. ---Matthew Hicks > Hello, > > in my design I'm using an Array "temp" and want it to by inferred as > BlockRAM. But the xst (9.1) only implements it on distibuted RAM: > > INFO:Xst:2664 - HDL ADVISOR - Unit <lsp_to_lpc> : The RAM <Mram_temp> > will be implemented on LUTs either because you have described an > asynchronous read or because of currently u > nsupported block RAM features. If you have described an asynchronous > read, making it synchronous would allow you to take advantage of > available block RAM resources, for optimized device usage and improved > timings. Please refer to your documentation for coding guidelines. > ---------------------------------------------------------------------- > - > | ram_type | Distributed | > | > ---------------------------------------------------------------------- > - > | Port A > | > | aspect ratio | 22-word x 32-bit | > | > | clkA | connected to signal <CLOCK> | rise > | > | weA | connected to signal <Mram_lpc_not0000> | > high | > | addrA | connected to signal <temp_idx1> | > | > | diA | connected to internal node | > | > | doA | connected to internal node | > | > ---------------------------------------------------------------------- > - > | Port B > | > | aspect ratio | 22-word x 32-bit | > | > | addrB | connected to signal <temp_idx2> | > | > | doB | connected to internal node | > | > ---------------------------------------------------------------------- > - > > I've looked through my design, but I can't find any asynchronous read? > Can anybody please take a look at this? > > architecture behav of lsp_to_lpc is > type STATE_TYPE is (WAITING, PART1, PART1_2, PART2, PART3, PART3_1, > PART3_2, PART3_3, PART3_4, PART4, PART5, PART6, PART7, PART7_1, > WRITE_OUT); > signal STATE : STATE_TYPE; > type memory_20B is array (0 to 9) of signed (15 downto 0); > signal lpc : memory_20B; > type memory_17_5B is array (0 to 9) of signed (13 downto 0); > signal lsp : memory_17_5B; > signal lsp_idx, lsp_idx2, lpc_idx : integer range 0 to 9; > type memory_88B is array (0 to 21) of signed (31 downto 0); > signal temp : memory_88B; > signal temp_idx1, temp_idx2 : integer range 0 to 21; > signal xout1, xout2, xin1, xin2 : signed (31 downto 0); > signal i : integer range 0 to 20; > signal j : integer range 0 to 11; > signal started : std_logic; > signal tmp_a, tmp_b : signed (31 downto 0); > begin > main : process (CLOCK, RESET) > variable temp_a, temp_b : signed (31 downto 0); > begin > if (RESET = '1') then > STATE <= WAITING; > i <= 0; > j <= 0; > DATA_OUT <= (others => '0'); > DONE <= '0'; > started <= '0'; > READY <= '1'; > xout1 <= (others => '0'); > xout2 <= (others => '0'); > xin1 <= (others => '0'); > xin2 <= (others => '0'); > lsp_idx <= 0; > lsp_idx2 <= 0; > lpc_idx <= 0; > temp_idx1 <= 0; > temp_idx2 <= 10; > tmp_a <= (others => '0'); > tmp_b <= (others => '0'); > elsif (CLOCK'event and CLOCK = '1') then > case STATE is > when WAITING => > DONE <= '0'; > if (START = '1' or started = '1') then > if (i < 10) then > READY <= '0'; > lsp(lsp_idx) <= ANGLE2X(DATA_IN)(15 downto 2); > lpc(lpc_idx) <= (others => '0'); > temp(temp_idx1) <= (others => '0'); > if (i < 9) then > lsp_idx <= lsp_idx + 1; > lpc_idx <= lpc_idx + 1; > end if; > temp_idx1 <= temp_idx1 + 1; > i <= i + 1; > started <= '1'; > else > xout1 <= (others => '0'); > xout2 <= (others => '0'); > started <= '0'; > i <= 0; > STATE <= PART1; > xin1 <= "00000000000100000000000000000000"; > xin2 <= "00000000000100000000000000000000"; > end if; > end if; > when PART1 => > if (temp_idx1 < 21) then > temp(temp_idx1) <= (others => '0'); > temp_idx1 <= temp_idx1 + 1; > else > temp(temp_idx1) <= (others => '0'); > temp_idx1 <= 0; > STATE <= PART1_2; > end if; > when PART1_2 => > if (j <= 10) then > STATE <= PART2; > else > STATE <= WRITE_OUT; > DONE <= '1'; > lpc_idx <= 0; > j <= 0; > end if; > when PART2 => > if (i < 20) then > lsp_idx <= i/2; > lsp_idx2 <= i/2 + 1; > temp_idx1 <= i; > temp_idx2 <= i + 2; > STATE <= PART3; > else > temp_idx1 <= 20; > temp_idx2 <= 21; > STATE <= PART5; > i <= 0; > end if; > when PART3 => > tmp_a <= temp(temp_idx1); -- temp(i) > tmp_b <= temp(temp_idx2); -- temp(i + 2) > temp_idx1 <= i; > STATE <= PART3_1; > when PART3_1 => > xout1 <= xin1 - MULT16_32_Q14(lsp(lsp_idx) & "00", tmp_a); > xout2 <= xin2 - MULT16_32_Q14(lsp(lsp_idx2) & "00", tmp_b); > temp(temp_idx1) <= xin1; -- temp(i) > temp_idx1 <= i + 1; > temp_idx2 <= i + 3; > STATE <= PART3_2; > when PART3_2 => > xout1 <= xout1 + temp(temp_idx1); -- temp(i + 1) > xout2 <= xout2 + temp(temp_idx2); -- temp(i + 3) > temp_idx1 <= i + 1; > STATE <= PART3_3; > when PART3_3 => > temp(temp_idx1) <= tmp_a; -- temp(i + 1) > temp_idx1 <= temp_idx1 + 1; > STATE <= PART3_4; > when PART3_4 => > temp(temp_idx1) <= xin2; -- temp(i + 2) > temp_idx1 <= temp_idx1 + 1; > STATE <= PART4; > when PART4 => > temp(temp_idx1) <= tmp_b; -- temp(i + 3) > xin1 <= xout1; > xin2 <= xout2; > i <= i + 4; > STATE <= PART2; > when PART5 => > xout1 <= xin1 + temp(temp_idx1); > xout2 <= xin2 - temp(temp_idx2); > if (j > 0) then > STATE <= PART6; > lpc_idx <= j - 1; > else > STATE <= PART7; > end if; > when PART6 => > if (xout1 + xout2 > 8388096) then > lpc(lpc_idx) <= "0111111111111111"; > elsif (xout1 + xout2 < -8388096) then > lpc(lpc_idx) <= "1000000000000001"; > else > lpc(lpc_idx) <= CUT(shift_right(xout1 + xout2 + > "00000000000000000000000010000000", 8)); > end if; > STATE <= PART7; > when PART7 => > temp(temp_idx1) <= xin1; > temp_idx1 <= temp_idx1 + 1; > STATE <= PART7_1; > when PART7_1 => > temp(temp_idx1) <= xin2; > xin1 <= (others => '0'); > xin2 <= (others => '0'); > j <= j + 1; > STATE <= PART1_2; > when WRITE_OUT => > if (i < 10) then > DATA_OUT <= lpc(lpc_idx); > if (i < 9) then > lpc_idx <= lpc_idx + 1; > end if; > i <= i + 1; > else > i <= 0; > lpc_idx <= 0; > lsp_idx <= 0; > temp_idx1 <= 0; > temp_idx2 <= 10; > STATE <= WAITING; > READY <= '1'; > end if; > end case; > end if; > end process main; > end behav; >Article: 114608
"Andrew Holme" <andrew@nospam.com> wrote in message news:eotnpd$ei1$1$830fa17d@news.demon.co.uk... > > [unformatted code snipped] > > Your code would be a lot easier to read if you indented it. I apologise. It was my newsreader that removed the indentation.Article: 114609
JustJohn wrote: > axalay wrote: > > XOR - is not detrct + or - phase shift. And I not use external phase > > detect chips. I whant do it in FPGA. And structure of phase detector > > from XAPP028 is not work! > > > > Vasiliy > > Vasiliy, > It works just fine, although the timing tools will give you grief > over the combinatorial feedback loop, and simulators may choke on it. > You might double check that your PU/PD are pumping in the right > direction, and that your external analog filter is correct. > > An altermative implementation uses a pair of FFs, one clocked high by > your feedback clock, one clocked high by the reference clock, and both > asynchronously reset when both are high. PU and PD are decoded when one > or the other FF is high. Slightly more simulator friendly. The HC4046 uses this topology. The OP could also drop in a 4046, and get the system working, then transfer pieces into the FPGA. That's a good way to confirm other parts are OK, plus you have a working reference for things like phase noise in the phase detector/charge pump sections. FPGA pumps will use the FPGA rails, so for lower noise (if that matters) you can drive analog switches from the FPGA -jgArticle: 114610
Is it possible to infer BRAMs (or any dual-port RAM) that has differing port widths? I can find no mention of this in the XST guide. StephenArticle: 114611
axalay wrote: > XOR - is not detrct + or - phase shift. And I not use external phase > detect chips. I whant do it in FPGA. And structure of phase detector > from XAPP028 is not work! > An XOR most certainly can work as a phase detector, *provided* the input frequencies are reasonably close. What it cannot do it give a valid output when the inputs differ significantly in frequency. (This may make it unsuitable for your use.) To see how it works, imagine two inputs of almost equal frequency, so the phase shifts slowly. When they are in phase, the XOR gives a zero output: when they are exactly out of phase it gives '1'. Used in a PLL, it will seek to give a 50-50 square-wave output, corresponding to a 90 degree phase difference. Your loop filter then integrates this to a voltage at 50% of Vdd. In fact (subject to the overall loop dynamics), XOR will work with more difference between the input frequencies than you might expect: it just won't work over as wide a range as the flipflop designs.Article: 114612
Not sure if anyone else will care to know about this, but I've found myself mentioning it to a few people, so I'll just put it out here for archival purposes. (I did pass this along to Xilinx, but I don't think any fix has propagated to the community yet.) I was writing a linux kernel driver for the icap, and I found what I believe to be an error in hwicap_v1_00_a\src\xhwicap_set_configuration.c. These comments refer to revision with header stamp: /* $Header: /devl/xcs/repo/env/Databases/ip2/processor/software/devel/hwicap/v1_00_a/src/xhwicap_set_configuration.c,v 1.4 2004/11/01 17:48:26 meinelte Exp $ */ When XhwIcap_SetConfiguration() is invoked with less than XHI_MAX_BUFFER_INTS words, lines 124-125 call XHwIcap_DeviceWrite() with BufferCount+1 words instead of BufferCount words. When the code finishes iterating through the for loop in lines 94-118, BufferCount is equal to I and equal to Size. So if Size was set to 4, BufferCount will equal 4, and calling XHwIcap_DeviceWrite() for BufferCount+1 words will actually write 5 words to the ICAP. In my case that was apparently writing an additional bogus word to the ICAP and thus causing CRC errors. When I change BufferCount+1 to BufferCount in line 124, my driver works as expected. People who always write full frames will probably not have run into this, but my driver had to write chunks of data as it received them from the kernel, and thus not split along frame boundaries.Article: 114613
hi everyone
I am doing a fpga project for my engineering course completion.
The project is to process an image caught by a digital camera(. I have
to store the image caught by the camera in fpga memory as a bit map
image and will find the average color of the image and to display it in
the lcd of fpga. I am using verilog . now please guide me with
the right fpga that i can go for. I hope one million gates are well
enough for this project. But I am not sure with the amount of RAM that
is needed. Is spartan 3 XCS 1000 of xilinx ok. I am not sure. Please
suggest me with right fpga and amount of memory needed for this project
and everything that i have to check before buying.
Article: 114614I'm sorry but my crystal ball is broken. How can we tell you how much memory you need unless you give us the resolution of the camera? Also, how does the camera ship out the image, ie what is the physical link layer: camera link, usb, etc??? "project help" <shahmdk@gmail.com> wrote in message news:1169333632.282565.160660@v45g2000cwv.googlegroups.com... > hi everyone > > I am doing a fpga project for my engineering course completion. > The project is to process an image caught by a digital camera(. I have > to store the image caught by the camera in fpga memory as a bit map > image and will find the average color of the image and to display it in > the lcd of fpga. I am using verilog . now please guide me with > the right fpga that i can go for. I hope one million gates are well > enough for this project. But I am not sure with the amount of RAM that > is needed. Is spartan 3 XCS 1000 of xilinx ok. I am not sure. Please > suggest me with right fpga and amount of memory needed for this project > and everything that i have to check before buying. >Article: 114615
I am sure that you want to use an evaluation board, available from the FPGA manufacturer or also from the distributor (Avnet in the xase of Xilinx). Without an eval board you are facing a lot of board design issues and delays. Don't even think about it. The most important parameter is the amount of memory available on that board. So you first have to decide how much RAM you need. The rest (averaging) is trivial. Good luck Peter Alfke, Xilinx Applications (from home) On Jan 20, 2:53 pm, "project help" <shah...@gmail.com> wrote: > hi everyone > > I am doing a fpga project for my engineering course completion. > The project is to process an image caught by a digital camera(. I have > to store the image caught by the camera in fpga memory as a bit map > image and will find the average color of the image and to display it in > the lcd of fpga. I am using verilog . now please guide me with > the right fpga that i can go for. I hope one million gates are well > enough for this project. But I am not sure with the amount of RAM that > is needed. Is spartan 3 XCS 1000 of xilinx ok. I am not sure. Please > suggest me with right fpga and amount of memory needed for this project > and everything that i have to check before buying.Article: 114616
One choice: http://www.digilentinc.com AustinArticle: 114617
Vasily Perhaps what you really want is a frequency detector? A phase detector is only useful when the two signals being compared are very, very close in frequency, such that a phase detector obtains a useful output. Please examine "frequency-phase detectors." That may provide you with some guidance, AustinArticle: 114618
> where can i find a description of the edif format. www.edif.org doesn't > have the syntax I can't address the larger question, but if you just need to read and parse edif, BYU has two good solutions: 1. Robust but slower: http://reliability.ee.byu.edu/edif 2. No longer supported but fast and great for custom uses: http://splish.ee.byu.edu/download/edifparser/edif_parser_download.html I'm using 2 and am very happy with it. It's based on an edif description (http://splish.ee.byu.edu/download/edifparser/edif.jj) that can be run through JTB and JavaCC. Incidentally, edif.jj gives you the edif syntax, although it doesn't provide any semantics.Article: 114619
Newbie problem:
I get some nasty horizontal jitter on vga display
controlled by a vga controller (see below) running
on a digilent nexys board. It looks like all scan lines
jitter relative to each other (couple of pixels left/right).
The problem is worse on the first 1/16th of the screen
and it is getting better below (still jitters on the bottom
though).
Looking at the hsyncs via an oscilloscope shows that
the pulses do actually slide left and right like crazy and
are really unstable (10-20ns jitter).
I tried to look at the output of a production vga adapter
and it looks more stable (do not jitter as much) and the
edges of the pulses are much more "square" (raise time is
much smaller). Another difference is with the voltage -
nexys uses 3.3v and it looks like the vga adapter I tried
has 5v output.
I looked all over the internet and it doesn't seem like
anybody else has this problem. Have anybody tried
to get a nice and stable picture via nexys vga?
What am I doing wrong? Is it supposed to be that
"imperfect"? How do I fix it?
The setup:
- 100Mhz nexys builtin oscillator clock is fed into mclk
input signal
- Desired output 800x600 72Hz (50MHz pixel clock)
- nexys vga (vga port + 12 resistors) is used (inserted into j8 slot)
-- variation of vga controller code (this is one of the ways
-- i tried
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity vga2 is
Port( mclk: in std_logic;
ssen: out std_logic_vector(3 downto 0);
led: out std_logic_vector(7 downto 0);
j8VGAR: out std_logic_vector(3 downto 0);
j8VGAG: out std_logic_vector(3 downto 0);
j8VGAB: out std_logic_vector(3 downto 0);
j8VGASync: out std_logic_vector(1 downto 0)); -- <0> - hs, <1> - vs
end vga2;
architecture Behavioral of vga2 is
signal hCount: std_logic_vector (11 downto 0);
signal hBlank: std_logic;
signal hSync: std_logic;
signal vCount: std_logic_vector (20 downto 0);
signal vBlank: std_logic;
signal vSync: std_logic;
begin
-- count pixels
process
constant pixClocks: integer := 2;
constant hMax: integer := 1040*pixClocks; -- line duration
constant hWidth: integer := 120*pixClocks; -- hsync width
constant hBack: integer := 61*pixClocks; -- line back porch
constant hFront: integer := 53*pixClocks; -- line front porch
constant vMax: integer := hMax*666; -- frame duration
constant vWidth: integer := hMax*6; -- vsync width
constant vBack: integer := hMax*21; -- frame back porch
constant vFront: integer := hMax*35; -- frame front porch
begin
wait until mclk = '1' and mclk'Event;
-- update horizontal counter
if hCount = hMax - 1 then hCount <= (others=>'0'); else hCount <= hCount +
1; end if;
-- update vertical counter
if vCount = vMax - 1 then vCount <= (others=>'0'); else vCount <= vCount +
1; end if;
-- update horizontal sync signal
if hCount = hMax - 1 then
hSync <= '1';
elsif hCount = hWidth - 1 then
hSync <= '0';
else
hSync <= hSync;
end if;
-- update vertical sync signal
if vCount = vMax - 1 then
vSync <= '0';
elsif vCount = vWidth - 1 then
vSync <= '1';
else
vSync <= vSync;
end if;
-- update horizontal blanking signal
if hCount = hWidth + hBack - 1 then
hBlank <= '0';
elsif hCount = hMax - hFront - 1 then
hBlank <= '1';
else
hBlank <= hBlank;
end if;
-- update vertical blanking signal
if vCount = vWidth + vBack - 1 then
vBlank <= '0';
elsif vCount = vMax - vFront - 1 then
vBlank <= '1';
else
vBlank <= vBlank;
end if;
end process;
-- Feed video data
process
begin
wait until mclk = '1' and mclk'Event;
if vBlank = '1' or hBlank = '1' then
j8VGAR <= (others => '0');
j8VGAG <= (others => '0');
j8VGAB <= (others => '0');
else
j8VGAR <= (others => '1');
j8VGAG <= (others => hCount(5));
j8VGAB <= (others => '1');
end if;
end process;
-- update leds
led <= (others => '0');
-- update segment indicators
ssen <= "1111";
-- vga2 sync signals
j8VGASync <= (0 => hSync, 1 => vSync );
end Behavioral;
Corer
Article: 114620On 2007-01-20, stephen.craven@gmail.com <stephen.craven@gmail.com> wrote: > Is it possible to infer BRAMs (or any dual-port RAM) that has differing > port widths? > > I can find no mention of this in the XST guide. I tried to do this once and was unable to get XST to figure it out. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 114621
"bm" <nospam@nospam.fr> writes: > Thanks for these relevant responses. > How would i make a "diff" between Sparc V7 & V8 ??? A yellow highlighter?Article: 114622
> Looking at the hsyncs via an oscilloscope shows that > the pulses do actually slide left and right like crazy and > are really unstable (10-20ns jitter). Are they clean ? (no ringing) If they're clean, but just too slow rising, you can try to change the IOB properties of the hsync output, try to add things like DRIVE=24 and/or SLEW=FAST (I'd try the DRIVE first, at 50MHz the FAST slew doesn't make much sense I think) SylvainArticle: 114623
> Looking at the hsyncs via an oscilloscope shows that > the pulses do actually slide left and right like crazy and > are really unstable (10-20ns jitter). Are they clean ? (no ringing) If they're clean, but just too slow rising, you can try to change the IOB properties of the hsync output, try to add things like DRIVE=24 and/or SLEW=FAST (I'd try the DRIVE first, at 50MHz the FAST slew doesn't make much sense I think) SylvainArticle: 114624
Antti wrote: > I wonder if thats only from Europe or is that something at Xilinx > server, all login attemps time-out today :( > > Antti > Is it only me, or does xilinx have problems again? <SNIP> Message from the NSAPI plugin: Internal Server failure, NSAPI plugin. Cannot continue. Build date/time: May 1 2006 12:12:04 Change Number: xxxxxx <SNAP> regards Thomas
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