Ray Andraka wrote: [User feedback that should have almost everyone in Xilinx cringing..] <snip>> OK, so for a better way. #1 Listen to the users of your software, and I > mean all of them, not just your biggest 5 accounts. #2, stop the > software folks from mucking with the software. Fix what is broken > before adding new features, and for Gosh sakes stop the gratuitous > changes that seem to break everything. #3, work on the support for the > software you have. #4, organize the answers data base, perhaps with a > pre-filter that asks you which device, version of ISE, and maybe > synthesis tool you are using so I don't get 1001 answers for ISE4.1 when > I am trying to use 7.1. #5, don't just cut off support for an older > version (eg 6.3sp3, which works better than 7.1 except the timing > parameters haven't been updated)Very good point : Xilinx: So HOW hard is it, to update the timing parameters ? Actually, SURELY Xilinx do that internally, otherwise HOW do they know they ARE moving forwards in SW, and not simply being carried by the silicon ??! if the newer version is still loaded> with fatal bugs. When I report a problem with 6.3, the only answer that > is returned is use 7.1 (never mind the fact that 7.1 did not work at all > until sp4 for any design I ran it on) #6. Fix the bugs in a major > release before committing all your effort to the next major release. #7 > Listen to your users, some of them do know what they are talking about.How about #8 : Get the SW writers to actually USE the tools ?! Some of the failings reported here, are frankly, stunningly stupid. eg Inverted outputs on CPLDs - I'd really LOVE to hear just how that flew thru all the supposed regression testing ?. --Let me guess - they only tested SW, and no one thought to try real silicon ?!> Things like the FIFO16 restrictions need to be in the user manual so > that the designer is aware of them before he design them in so that he > can work around the limitations. Easy to work around if given the > information. A real pain the tail to find the problem if you are not > aware of the limitations, and none too fun to rework the design to work > within the limitations when you do learn about them. For known bugs in > the software, there really should be an errata sheet listing the known > issues that can trip up a design (like the pipeline register remapping > or what ever you call it) so that when you run into a problem like this > you have a prayer of finding an answer record on it. Maybe all it takes > is a refinement of the search engine. I don't know, that isn't my area > of expertise. I think the fact that you also didn't post any relevant > answer records to Brads post that started this should be a flag to you > showing you that the system isn't working too.This is something of a catch 22: To fully document problems, Xilinx must first understand them. However, if they understood them, they would be fixed/eliminated very quickly. There is a natural vested interest in NOT listing too many bugs in SW. It is classic large company spin, to appear to give support and information, when actually doing neither.> > Another suggestion is better testing of your software before you release > it, not just on the mainstream push the big green button to make a 40 > Mhz design designs either, but some with some handcrafting that are > pushing the clock capabilities of the devices.I'm sure Ray could give Xilinx some very good 'real world' test cases ? While the compile> completion times have gotten remarkably good, the quality of results for > a pretty well optimized design (one that includes tight floorplanning) > have fallen off with each major release since 4.1. I know other users > have remarked as such here, so I know I am not the only one. The > regression testing really does need to include the full spectrum of > designs, unless Xilinx really is trying to kill off the RLOC as was > speculated here many years ago. > > OK, sorry about the rant (well, not really). This thread just happened > to pour vinegar into an open wound, and well, your answer did nothing to > soothe the pain.-jg
Xilinx Virtex-4 BRAM-16 Simulation
Started by ●January 13, 2006
Reply by ●January 15, 20062006-01-15
Reply by ●January 15, 20062006-01-15
>There is a natural vested interest in NOT listing too many bugs in SW.Not where I come from. Doug Clark wrote a great paper - "Bugs are Good". Unfortunately, I don't think it's available online. Context is roughly: Don't shoot the messenger. Praise the people who find the problems before you tape out. Discuss the bugs you find. Why weren't they found sooner? Where are there similar structures that should be examined/probed? If you can accurately keep track of bugs, then you can plot bugs discovered over time. When that falls off it's time to ship. I think it's a culture thing. It's much better to find bugs sooner. The trick is to make sure that everybody understands that - management too. You need somethingthings like a senior designer standing up in public and saying thanks to a new hire. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
Reply by ●January 15, 20062006-01-15
Hal Murray wrote:>>There is a natural vested interest in NOT listing too many bugs in SW. > > > Not where I come from. > > Doug Clark wrote a great paper - "Bugs are Good". Unfortunately, I > don't think it's available online. > > Context is roughly: > > Don't shoot the messenger. Praise the people who find the problems > before you tape out. > > Discuss the bugs you find. Why weren't they found sooner? > Where are there similar structures that should be examined/probed? > > If you can accurately keep track of bugs, then you can plot bugs > discovered over time. When that falls off it's time to ship. > > > I think it's a culture thing. It's much better to find bugs sooner. > The trick is to make sure that everybody understands that - management > too. You need somethingthings like a senior designer standing up in public > and saying thanks to a new hire.100% Agree - for a properly-run engineering company. However, as companies get more dominated by market-droids, and someone suggests this info is made more public/user accessible, that's where you will see the push-back : Write your own Dilbert lines here : " Hang on, All these defect reports makes our SW look bad - quality was better before" " Those defects will only affect very few customers, so why tell everyone about them ? " Xilinx press releases show some of this mindset already : My present most entertaining favourite is the ISE 8.1i release that says :: "WebPACK 8.1i�s ISE Fmax Technology ... up to 70 percent faster performance than competing FPGA products" [Is this a laundry product, or Engineering SW they are selling ? ] Sounds great, warm fuzzies all round, until you look for meaning.... - Note, no comparison with EARLIER ISE releases, only with someone else's (un-named) offering, and then it's the meanginless "up to" caveat. There is another end to this scale as well, which is "down to" - why is that never published in these press releases ? :) -jg
Reply by ●January 15, 20062006-01-15
OK, well, I think I have my addressing fixed, and the code below
is for a 9 bit ROM, which is what I originally wanted. It seems to
generate acceptable output, at least for small numbers. I am using
the new ISE 8.i simulator. I will test it with larger values later.
Thanks Ray and Sylvain for taking the time to pick out my mistake.
I should have known.
A number of new questions arise:
1) Is the code around the "begin" keyword, which maps the inputs
to the primitive RAMB16 (BRAM or Block RAM) acceptable or
is there a more concise/better method?
2) I initially went to the V4 library guide and found this primitive.
I did not see there the RAMB_Sx_Sy primitives of Spartan yore,
which lead me to believe that they are abandoned in Virtex-4.
The Xilinx Virtex-4 User Guide ( ug070.pdf ) page 133 would
lead one to believe that they are available. What is the story here?
3) Generally, I would like to transport my future designs between
Spartan3s and Virtex-4 effortlessly. Are their any tips, ap notes,
or other information out there on how to do this?
4) The INIT_xx => sytax is clumsy. Especially if I choose
to use the ninth bit. What alternatives do I have?
5) I have been searching Google for code examples with the words
RAMB16 and std_logic. Is there any primitive or keyword
specific to Virtex-4 that would further refine my search?
6) I did not see the INIT value on the ISE 8.1 simulation which
I expect to see at time 0. Is this a glitch in the 8.1 simulator?
Regards,
Brad Smallridge
aivision dot com
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
library UNISIM;
use UNISIM.VComponents.all;
entity bram9p is
port (
clkb : IN std_logic;
enb : IN std_logic;
ssrb : IN std_logic;
regceb : IN std_logic;
addrb : IN std_logic_VECTOR(11 downto 0);
web : IN std_logic;
doutb : OUT std_logic_VECTOR( 8 downto 0) );
end bram9p;
architecture Behavioral of bram9p is
signal addrb15 : std_logic_vector(14 downto 0);
signal dob32 : std_logic_vector(31 downto 0);
signal dopb4 : std_logic_vector( 3 downto 0);
signal web4 : std_logic_vector( 3 downto 0);
begin
addrb15(14 downto 3) <= addrb;
addrb15( 2 downto 0) <= "000";
doutb(7 downto 0) <= dob32(7 downto 0);
doutb(8) <= dopb4(0);
-- Update all web bits,
-- otherwise only some addresses will be written.
web4(0) <= web;
web4(1) <= web;
web4(2) <= web;
web4(3) <= web;
-- RAMB16: Virtex-4 16k+2k Parity Paramatizable BlockRAM
-- Xilinx HDL Language Template version 8.1i
RAMB16_inst : RAMB16
generic map (
DOA_REG => 0, -- Optional output registers on the A port (0 or 1)
DOB_REG => 0, -- Optional output registers on the B port (0 or 1)
INIT_A => X"000000000", -- Initial values on A output port
INIT_B => X"000000001", -- Initial values on B output port
INVERT_CLK_DOA_REG => FALSE, -- TRUE or FALSE
INVERT_CLK_DOB_REG => FALSE, -- TRUE or FALSE
RAM_EXTENSION_A => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
RAM_EXTENSION_B => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
READ_WIDTH_A => 9, -- Valid values are 1,2,4,9,18 or 36
READ_WIDTH_B => 9, -- Valid values are 1,2,4,9,18 or 36
SIM_COLLISION_CHECK => "NONE", --
"ALL","WARNING_ONLY","GENERATE_X_ONLY,"NONE
SRVAL_A => X"000000000", -- Port A ouput value upon SSR assertion
SRVAL_B => X"000000002", -- Port B ouput value upon SSR assertion
WRITE_MODE_A => "READ_FIRST", -- WRITE_FIRST, READ_FIRST or NO_CHANGE
WRITE_MODE_B => "READ_FIRST", -- WRITE_FIRST, READ_FIRST or NO_CHANGE
WRITE_WIDTH_A => 9, -- 1,2,4,9,18 or 36
WRITE_WIDTH_B => 9, -- 1,2,4,9,18 or 36
-- The following INIT_xx declarations specify the initial contents of
the RAM
INIT_00 =>
X"1F1E1D1C1B1A191817161514131211100F0E0D0C0B0A09080706050403020100",
INIT_01 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_02 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_03 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_04 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_05 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_06 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_07 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_08 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_09 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0A =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0B =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0C =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0D =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0E =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_0F =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_10 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_11 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_12 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_13 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_14 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_15 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_16 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_17 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_18 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_19 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1A =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1B =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1C =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1D =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1E =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_1F =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_20 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_21 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_22 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_23 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_24 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_25 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_26 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_27 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_28 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_29 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2A =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2B =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2C =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2D =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2E =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_2F =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_30 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_31 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_32 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_33 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_34 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_35 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_36 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_37 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_38 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_39 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3A =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3B =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3C =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3D =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3E =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INIT_3F =>
X"0000000000000000000000000000000000000000000000000000000000000000",
-- The next set of INITP_xx are for the parity bits
INITP_00 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_01 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_02 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_03 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_04 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_05 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_06 =>
X"0000000000000000000000000000000000000000000000000000000000000000",
INITP_07 =>
X"0000000000000000000000000000000000000000000000000000000000000000")
port map (
CASCADEOUTA => open, -- 1-bit cascade output
CASCADEOUTB => open, -- 1-bit cascade output
DOA => open, -- 32-bit A port Data Output
DOB => dob32, -- 32-bit B port Data Output
DOPA => open, -- 4-bit A port Parity Output
DOPB => dopb4, -- 4-bit B port Parity Output
ADDRA => (others=>'0'), -- 15-bit A port Address Input
ADDRB => addrb15, -- 15-bit B port Address Input
CASCADEINA => '0', -- 1-bit cascade A input
CASCADEINB => '0', -- 1-bit cascade B input
CLKA => '0', -- Port A Clock
CLKB => clkb, -- Port B Clock
DIA => (others=>'0'), -- 32-bit A port Data Input
DIB => (others=>'0'), -- 32-bit B port Data Input
DIPA => (others=>'0'), -- 4-bit A port parity Input
DIPB => (others=>'0'), -- 4-bit B port parity Input
ENA => '0', -- 1-bit A port Enable Input
ENB => enb, -- 1-bit B port Enable Input
REGCEA => '0', -- 1-bit A port register enable
input
REGCEB => regceb, -- 1-bit B port register enable
input
SSRA => '0', -- 1-bit A port Synchronous
Set/Reset Input
SSRB => ssrb, -- 1-bit B port Synchronous
Set/Reset Input
WEA => "0000", -- 4-bit A port Write Enable
Input
WEB => web4 ); -- 4-bit B port Write Enable
Input
end Behavioral;
