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
Thanx Mike! :) :) yes works fine now:)Article: 125226
On 18 Okt., 12:27, xenix <last...@gmail.com> wrote: > Hello all, I would like to ask if i can install in my computer 2 > different versions of EDK, one older than the other. > > O/S : Windows XP > > regards > xenix yesArticle: 125227
xenix wrote: > Hello all, I would like to ask if i can install in my computer 2 > different versions of EDK, one older than the other. > > O/S : Windows XP > > regards > xenix Yes, but you may find that you have to muck about with environment variables such as XILINX, XILINX_EDK, and LMC_HOME when changing between which version you're running. -- Philip Potter pgp <at> doc.ic.ac.ukArticle: 125228
On 18 Okt., 11:00, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Antti wrote: > > but - global or not, a 64 bit shift register clocked at 4MHz should > > work in ANY modern FPGA no matter what. > > there can not be any setup or hold violation. and the same erratic > > shift was also happening at even lower clock, below 2MHz. > > > and yes I play some more with the global nets, they seem to be a key > > in Actel technology. > > If this is clocked from a uC, one thing you could do, is add > a loop readback - where you either simply use the SR as > a delay line, and check you get back what left 64 clocks ago, > or add a Load option, so you can read back any latched nodes, > to verify their content ? > > -jg Hi Jim, yes I can add the readback path, its available, but well 4 LED on the shift register if they are wrong, then something is wrong. the story seems to be more and more a problem :( yesterday ONE P&R worked it used 28 bit register not 64 today I did rerung the desing from yesterday (with 28 shift reg) with Synplify 8.9 and i see the same wrong pattern 1011 (not 1001) on the LEDs again! same behaviour 2 different PCB when I take the programming file from yesterday it works. simple re-run P&R version doesnt. so it doesnt seem to be synplify issue as versions 8.8 and 8.9 seem to have same behaviour. I was so happy yesterday when the shorter shift register worked that I did not test multiply P&R runs but now i am stuck again. ok, I can convert the 24 shift to 1 shift 8 and 2 latches, etc.. but the puzzle remains! AnttiArticle: 125229
On Oct 18, 3:27 am, xenix <last...@gmail.com> wrote: > Hello all, I would like to ask if i can install in my computer 2 > different versions of EDK, one older than the other. > > O/S : Windows XP > > regards > xenix yes. to switch between them, edit the xilinx and xilinx_edk environment variables. i always have this setup because sometimes the new version breaks my compile. and sometimes the difference is subtle and i don't notice for months. nb: edk will only run with the ise of the same version. alan nishiokaArticle: 125230
On Oct 17, 4:19 pm, Antti <Antti.Luk...@googlemail.com> wrote: > On 17 Okt., 23:15, Dave <dhsch...@gmail.com> wrote: > > > > > Antti, > > > Could you fix the typo on the line with the do64(62 downto 0) > > assignment - there's an array length mismatch. Also, what is the > > definition of do64 - std_logic_vector(63 downto 0)? > > > On Oct 17, 4:44 pm, Antti <Antti.Luk...@googlemail.com> wrote: > > > > Hi ho > > > > here is code > > > > process (m_sck) begin > > > if (m_sck'event and m_sck=3D'1') then > > > do64(62 downto 0) <=3D do64(62 downto 0) & M_DI; > > > end if; > > > end process; > > > LEDS <=3D do64s(63 downto 60); > > > > M_DI, M_SCK are driven by external MCU SPI interface. > > > the MCU send either > > > 0x90 00 00 00 00 00 00 00 > > > or > > > 0x00 00 00 00 00 00 00 00 > > > > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1 > > > when the FPGA is full, there will blink all off, then 1-1-0-1 > > > repeating same pattern, not randomness > > > > changing maxfanout in synplify will change the erratic behaviour but I > > > have not managed to get the shift register ever work in case where > > > FPGA is really full. > > > > SPI clock is 4MHz (or lower doesn seem to make any difference) > > > > this time I am giving up, that is not trying to force the shift > > > register to work, but find solution that works > > > > the problem only occourcs on Actel FPGA, and yes yes it works in > > > s=EDmulation it works in xilinx FPGA, etc.. > > > > Antti > > > who this time really doesnt know the solution :(- Zitierten Text ausb= lenden - > > > - Zitierten Text anzeigen - > > sorry my eyes see double(almost, just hurt), i cleaned the code and > madetypo > > signal do64 : std_logic_vector(63 downto 0) ; > > process (m_sck) begin > if (m_sck'event and m_sck=3D'1') then > do64(63 downto 0) <=3D do64(62 downto 0) & M_DI; > end if; > end process; > LEDS <=3D do64(63 downto 60); The code seems pretty straight forward. One question though: are you expecting the groups of four output bits to line up on some magical boundary? If so, you'd obviously need a sync or reset pulse. Ignoring the four bit alignment, is m_sck landing on the dedicated clocking resources of the Actel part? If so, I'm guessing your problem has nothing to do with the the shift register code. What is the toggle rates of m_sck compared to M_DI, and just as important, the clock to data alignment between the two? Have you brought m_sclk out an I/O pin to verify its frequency and phase relationship with M_DI? Brought M_DI back out an I/O pin after being sampled by m_sck to verify that it's being sampled correctly? Have fun, MarcArticle: 125231
On 18 Okt., 12:47, Marc Randolph <mr...@my-deja.com> wrote: > On Oct 17, 4:19 pm, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > > > On 17 Okt., 23:15, Dave <dhsch...@gmail.com> wrote: > > > > Antti, > > > > Could you fix the typo on the line with the do64(62 downto 0) > > > assignment - there's an array length mismatch. Also, what is the > > > definition of do64 - std_logic_vector(63 downto 0)? > > > > On Oct 17, 4:44 pm, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > Hi ho > > > > > here is code > > > > > process (m_sck) begin > > > > if (m_sck'event and m_sck=3D'1') then > > > > do64(62 downto 0) <=3D do64(62 downto 0) & M_DI; > > > > end if; > > > > end process; > > > > LEDS <=3D do64s(63 downto 60); > > > > > M_DI, M_SCK are driven by external MCU SPI interface. > > > > the MCU send either > > > > 0x90 00 00 00 00 00 00 00 > > > > or > > > > 0x00 00 00 00 00 00 00 00 > > > > > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1 > > > > when the FPGA is full, there will blink all off, then 1-1-0-1 > > > > repeating same pattern, not randomness > > > > > changing maxfanout in synplify will change the erratic behaviour bu= t I > > > > have not managed to get the shift register ever work in case where > > > > FPGA is really full. > > > > > SPI clock is 4MHz (or lower doesn seem to make any difference) > > > > > this time I am giving up, that is not trying to force the shift > > > > register to work, but find solution that works > > > > > the problem only occourcs on Actel FPGA, and yes yes it works in > > > > s=EDmulation it works in xilinx FPGA, etc.. > > > > > Antti > > > > who this time really doesnt know the solution :(- Zitierten Text au= sblenden - > > > > - Zitierten Text anzeigen - > > > sorry my eyes see double(almost, just hurt), i cleaned the code and > > madetypo > > > signal do64 : std_logic_vector(63 downto 0) ; > > > process (m_sck) begin > > if (m_sck'event and m_sck=3D'1') then > > do64(63 downto 0) <=3D do64(62 downto 0) & M_DI; > > end if; > > end process; > > LEDS <=3D do64(63 downto 60); > > The code seems pretty straight forward. One question though: are you > expecting the groups of four output bits to line up on some magical > boundary? If so, you'd obviously need a sync or reset pulse. > > Ignoring the four bit alignment, is m_sck landing on the dedicated > clocking resources of the Actel part? If so, I'm guessing your > problem has nothing to do with the the shift register code. What is > the toggle rates of m_sck compared to M_DI, and just as important, the > clock to data alignment between the two? Have you brought m_sclk out > an I/O pin to verify its frequency and phase relationship with M_DI? > Brought M_DI back out an I/O pin after being sampled by m_sck to > verify that it's being sampled correctly? > > Have fun, > > Marc- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - the M_SCK and M_DI phase relation is perfect. there is no change in (wrong) behavour depending on the M_SCK frequency, 4Mhz, 500Khz exactly the same odd behaviour after the shit there is sync pulse to latch the values but its not related the the sync or SPI select, if I disable all sync and select signal switching the odd behaviour remains I send 0x00 then wait 1 second send then 0x90 and I see 2 LED on not 1 I have 1 P&R run, that works, all previous and later bitstream files have odd behaviour the fun way past gone in this game. need get it working one way or another. AnttiArticle: 125232
Antti wrote: > > but - global or not, a 64 bit shift register clocked at 4MHz should > work in ANY modern FPGA no matter what. > there can not be any setup or hold violation. and the same erratic > shift was also happening at even lower clock, below 2MHz. > Not true : if it is an internal hold problem due to your use of local routing for a clock, the problem will happen at ANY clock frequency ( i.e., the data from bit N-1 is getting to bit N before the clock ) I'd expect Neill's suggestion to use a clock spline would fix the problem. If you can't manage to convince the tools to use a clock spline, a hack to work around the problem would be to stick some dummy logic (made un- optimizable somehow) between each bit of the shift register to slow down the data path. BrianArticle: 125233
On 18 Okt., 13:30, Brian Davis <brimda...@aol.com> wrote: > Antti wrote: > > > but - global or not, a 64 bit shift register clocked at 4MHz should > > work in ANY modern FPGA no matter what. > > there can not be any setup or hold violation. and the same erratic > > shift was also happening at even lower clock, below 2MHz. > > Not true : if it is an internal hold problem due to your use of local > routing for a clock, the problem will happen at ANY clock frequency > ( i.e., the data from bit N-1 is getting to bit N before the clock ) > > I'd expect Neill's suggestion to use a clock spline would fix the > problem. > > If you can't manage to convince the tools to use a clock spline, a > hack to > work around the problem would be to stick some dummy logic (made un- > optimizable > somehow) between each bit of the shift register to slow down the data > path. > > Brian yes me stupid already fix AnttiArticle: 125234
On Oct 18, 2:54 am, Antti <Antti.Luk...@googlemail.com> wrote: > On 18 Okt., 09:37, nei...@pipstechnology.co.uk wrote: > > > > > On 17 Oct, 21:44, Antti <Antti.Luk...@googlemail.com> wrote: > > > > Hi ho > > > > here is code > > > > process (m_sck) begin > > > if (m_sck'event and m_sck=3D'1') then > > > do64(62 downto 0) <=3D do64(62 downto 0) & M_DI; > > > end if; > > > end process; > > > LEDS <=3D do64s(63 downto 60); > > > > M_DI, M_SCK are driven by external MCU SPI interface. > > > the MCU send either > > > 0x90 00 00 00 00 00 00 00 > > > or > > > 0x00 00 00 00 00 00 00 00 > > > > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1 > > > when the FPGA is full, there will blink all off, then 1-1-0-1 > > > repeating same pattern, not randomness > > > > changing maxfanout in synplify will change the erratic behaviour but I > > > have not managed to get the shift register ever work in case where > > > FPGA is really full. > > > > SPI clock is 4MHz (or lower doesn seem to make any difference) > > > > this time I am giving up, that is not trying to force the shift > > > register to work, but find solution that works > > > > the problem only occourcs on Actel FPGA, and yes yes it works in > > > s=EDmulation it works in xilinx FPGA, etc.. > > > > Antti > > > who this time really doesnt know the solution :( > > > So is m_sck actually using global routing, or has it been routed > > normally? > > > I've seen similar problems when clocks have been routed using local > > nets. I would suggest forcing m_sck to use a global net, or since > > your using Actel you could force it on to one of the local global > > spines. I can't remember how to do it, but I know there is an app > > note saying what constraints are needed. > > > Neill.- Zitierten Text ausblenden - > > > - Zitierten Text anzeigen - > > with defaul maxfanout of 12 synplify insert some 5 buffer in the M_SCK > path > global clocks are all used, because of routing constraints some set- > reset nets need to be driven by global nets otherise designer will use > 2 cells for 1 flip flop, the FPGA is very full so I used the global > nets first to optimize for smallest FPGA resource useage. > > but - global or not, a 64 bit shift register clocked at 4MHz should > work in ANY modern FPGA no matter what. > there can not be any setup or hold violation. and the same erratic > shift was also happening at even lower clock, below 2MHz. > > and yes I play some more with the global nets, they seem to be a key > in Actel technology. > > Antti Hello Antii, It does not matter how slow you clock it, you can still have hold violations if the clock skew between a source and destination register exceeds the data path delay from the source to the destination, and the clock arrives at the destination after it arrives at the source. Since a problem like this would be dependent on the place and route results, it sounds like it fits your symptoms. Have you run static timing analysis on this design? Your console looks interesting. I had recently been looking at the One Laptop Per Child web site, so it occurred to me that you must be working on your own One Console Per Child project. The nice thing about that is there is no need for it to be a non-profit. OCPC is the natural steady state of the world. Or maybe its two. Or three? Regards, John McCaskill www.fastertechnology.comArticle: 125235
On 18 Okt., 12:44, Antti <Antti.Luk...@googlemail.com> wrote: > On 18 Okt., 11:00, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > > > > > > > Antti wrote: > > > but - global or not, a 64 bit shift register clocked at 4MHz should > > > work in ANY modern FPGA no matter what. > > > there can not be any setup or hold violation. and the same erratic > > > shift was also happening at even lower clock, below 2MHz. > > > > and yes I play some more with the global nets, they seem to be a key > > > in Actel technology. > > > If this is clocked from a uC, one thing you could do, is add > > a loop readback - where you either simply use the SR as > > a delay line, and check you get back what left 64 clocks ago, > > or add a Load option, so you can read back any latched nodes, > > to verify their content ? > > > -jg > > Hi Jim, > > yes I can add the readback path, its available, but well 4 LED on the > shift register if they are wrong, then something is wrong. > > the story seems to be more and more a problem :( > yesterday ONE P&R worked it used 28 bit register not 64 > > today I did rerung the desing from yesterday (with 28 shift reg) with > Synplify 8.9 > and i see the same wrong pattern 1011 (not 1001) on the LEDs again! > same behaviour 2 different PCB > when I take the programming file from yesterday it works. > simple re-run P&R version doesnt. > > so it doesnt seem to be synplify issue as versions 8.8 and 8.9 seem to > have same behaviour. > > I was so happy yesterday when the shorter shift register worked that I > did not test multiply P&R runs > but now i am stuck again. > ok, I can convert the 24 shift to 1 shift 8 and 2 latches, etc.. > > but the puzzle remains! > > Antti- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - Ok, this time it looks like solved. feel sosososoo stuuupid. of course the internal skew of clocks is important, so adding manually a global clock buffer seem have cured that. still pending of longer testing, but it looks like ok now. what made me wonder was that the "wrong" pattern was always the same, across multiply P&R runs. I assumed wrongly that mockup of the internal clock can have repeateable same failure, and specially on register lengts 64 and 28, same wrong pattern 1001 > 1011 !! there was NO PRIZE offered for this quiz3 as I did not know the solution, but I received private mail, what was helpful, that email arrived some minutes after I had forced a globabl buffer into the design myself, but I do consider it fair to offer similar prize to that party also. that email just told me to force the global net, with good reasoning for that. Antti is feeling little stupid but also little happier (in the hope the quiz3 issue is really solved)Article: 125236
On 18 Okt., 13:38, John McCaskill <jhmccask...@gmail.com> wrote: > On Oct 18, 2:54 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > > > On 18 Okt., 09:37, nei...@pipstechnology.co.uk wrote: > > > > On 17 Oct, 21:44, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > Hi ho > > > > > here is code > > > > > process (m_sck) begin > > > > if (m_sck'event and m_sck=3D'1') then > > > > do64(62 downto 0) <=3D do64(62 downto 0) & M_DI; > > > > end if; > > > > end process; > > > > LEDS <=3D do64s(63 downto 60); > > > > > M_DI, M_SCK are driven by external MCU SPI interface. > > > > the MCU send either > > > > 0x90 00 00 00 00 00 00 00 > > > > or > > > > 0x00 00 00 00 00 00 00 00 > > > > > symptoms: when FPGA is not full, the LED blink, all OFF, 1-0-0-1 > > > > when the FPGA is full, there will blink all off, then 1-1-0-1 > > > > repeating same pattern, not randomness > > > > > changing maxfanout in synplify will change the erratic behaviour bu= t I > > > > have not managed to get the shift register ever work in case where > > > > FPGA is really full. > > > > > SPI clock is 4MHz (or lower doesn seem to make any difference) > > > > > this time I am giving up, that is not trying to force the shift > > > > register to work, but find solution that works > > > > > the problem only occourcs on Actel FPGA, and yes yes it works in > > > > s=EDmulation it works in xilinx FPGA, etc.. > > > > > Antti > > > > who this time really doesnt know the solution :( > > > > So is m_sck actually using global routing, or has it been routed > > > normally? > > > > I've seen similar problems when clocks have been routed using local > > > nets. I would suggest forcing m_sck to use a global net, or since > > > your using Actel you could force it on to one of the local global > > > spines. I can't remember how to do it, but I know there is an app > > > note saying what constraints are needed. > > > > Neill.- Zitierten Text ausblenden - > > > > - Zitierten Text anzeigen - > > > with defaul maxfanout of 12 synplify insert some 5 buffer in the M_SCK > > path > > global clocks are all used, because of routing constraints some set- > > reset nets need to be driven by global nets otherise designer will use > > 2 cells for 1 flip flop, the FPGA is very full so I used the global > > nets first to optimize for smallest FPGA resource useage. > > > but - global or not, a 64 bit shift register clocked at 4MHz should > > work in ANY modern FPGA no matter what. > > there can not be any setup or hold violation. and the same erratic > > shift was also happening at even lower clock, below 2MHz. > > > and yes I play some more with the global nets, they seem to be a key > > in Actel technology. > > > Antti > > Hello Antii, > > It does not matter how slow you clock it, you can still have hold > violations if the clock skew between a source and destination register > exceeds the data path delay from the source to the destination, and > the clock arrives at the destination after it arrives at the source. > > Since a problem like this would be dependent on the place and route > results, it sounds like it fits your symptoms. > > Have you run static timing analysis on this design? > > Your console looks interesting. I had recently been looking at the > One Laptop Per Child web site, so it occurred to me that you must be > working on your own One Console Per Child project. The nice thing > about that is there is no need for it to be a non-profit. OCPC is the > natural steady state of the world. Or maybe its two. Or three? > > Regards, > > John McCaskillwww.fastertechnology.com- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - Hi John, read my other reply. no this problem did not happen with the xilinx FPGA. I am working towards: "Mission impossible II (tecnical)" in my life. Once i have achived (something technical) that i would consider impossible havent I had done it. my MI-2(tech.) involves developing an ASIC replacement with FPGA technology with total BOM cost limit of 6.00 USD. Additional constraints like little PCB space, memory latency requirments, etc apply. You can imagine things happen on that path. I am pushing a very small FPGA to its limits, and forgot the obvious. Also the struggle with the quiz1 problem did eat a lot of my brains, and I havent had my 1-per-year-take-a-longer-breath yet this year. thanks for nice comment on the console. I hope it will have a small fun club, specially as OCPC-1 is targetting sale price below 20 USD ;) AnttiArticle: 125237
Hi everybody! I would like to get advises about good books in dynamic reconfiguration using FPGAs. I need theoretical (algorithms, methods) as well as practical information. Thanks in advanceArticle: 125238
On 18 Okt., 14:52, GaLaKtIkUs=99 <taileb.me...@gmail.com> wrote: > Hi everybody! > I would like to get advises about good books in dynamic > reconfiguration using FPGAs. I need theoretical (algorithms, methods) > as well as practical information. > > Thanks in advance get a book "black magic" first :) AnttiArticle: 125239
Hi folks!
A bit of VHDL trivia.
What I want is the reverse of:
one_hot_gen: for i in 0 to 15 generate
begin
one_hot(i) <= '1' when CONV_INTEGER(address) = i else '0';
end generate;
the only idea I had contains 'Z's, which the tools will swallow and
convert to logic - it works, but there _has_ to be a nicer way?
address <= "0000" when one_hot(0) = '1' else "ZZZZ";
address_gen: for i in 1 to 15 generate
begin
address2 <= CONV_STD_LOGIC_VECTOR(CONV_UNSIGNED(i, 4), 4)
when one_hot(i) = '1'
and CONV_INTEGER(one_hot(i - 1 downto 0)) = 0
else "ZZZZ";
end generate;
Any ideas?
- Philip
--
Democracy: Three wolves and a sheep voting on what's
for dinner.
Article: 125240On Oct 18, 5:53 am, Ben <leowy...@gmail.com> wrote: > Hi everyone, pardon me but I'm pretty new to this. > > I'm using a Spartan 3 right now, and I'm trying to provide source > synchronous clock clocking to a SDR SDRAM using DDR register. > The component looks something like this: > > OFDDRCPE sdram0OutputClock ( > .Q(sdram0_clk), > .C0(sdram_clk), > .C1(~sdram_clk), > .CE(1'b1), > .CLR(1'b0), > .D0(1'b1), > .D1(1'b0), > .PRE(1'b0) ); > > The input clock is sdram_clk and the output clock to the sdram is > sdram0_clk > The problem is I'm not sure whether I need to specify any extra > constraints in the UCF file for sdram0_clk. > Is there anything else to take note of? > Are sdram_clk and sdram0_clk considered as different clock domains? If > so how do I get the data back to the sdram_clk domain? > > Thanks in advance, > Ben. Once you've assigned the I/O standard of the pin, there's not much else you can do with constraints. The clock to the DDR flip-flop should be on a global net, and there is nothing that the tools can do to change the clock to output timing. However adding a timing constraint for clock to output will cause the actual timing to be reported in the post p&r static timing report, which is useful. Also I noticed you're using clock and ~clock rather than the clock and 180 degree phase-shifted clock. Remember that for DDR the duty cycle is very important so make sure your clock is duty-cycle corrected in a DCM. Regards, GaborArticle: 125241
how about a big case statement ? case OneHot is when X"0001" => Address <= X"0"; when X"0002" => Address <= X"1"; when X"0004" => Address <= X"2"; when X"0008" => Address <= X"3"; when X"0010" => Address <= X"4"; when X"0020" => Address <= X"5"; when X"0040" => Address <= X"6"; when X"0080" => Address <= X"7"; when X"0100" => Address <= X"8"; when X"0200" => Address <= X"9"; when X"0400" => Address <= X"A"; when X"0800" => Address <= X"B"; when X"1000" => Address <= X"C"; when X"2000" => Address <= X"D"; when X"4000" => Address <= X"E"; when others => Address <= X"F"; end case;Article: 125242
jan.kindt wrote: > how about a big case statement ? Gets too big if the width grows, and doesn't work with generic widths... :( - Philip -- Democracy: Three wolves and a sheep voting on what's for dinner.Article: 125243
> I would like to get advises about good books in dynamic > reconfiguration using FPGAs. I need theoretical (algorithms, methods) > as well as practical information. Don't we all!? ;) I think those "books" are still being written, and presently exist mainly in the form of conference papers and journal articles.Article: 125244
"Philip Herzog" <phq@arcor.de> wrote in message news:471768C4.90800@arcor.de... > jan.kindt wrote: >> how about a big case statement ? > > Gets too big if the width grows, and doesn't work with generic widths... > :( > > - Philip > Hi Philip, Perhaps comp.lang.vhdl might be a better place to ask? HTH., Syms.Article: 125245
Eric, F/A rarely shows us anything useful. If the part has been fried (electrical over-stress) that is easily determined with an ohmmeter. If the part has a particle defect, or some other process defect, we already knew these parts are from the first ever lots of a new process, and yes, that happens quite often. Statistics on defects are kept with "defect monitor" vehicles, so we don't care to tear apart one known early part and see one defect we already have seen before in the monitors. As long as the part is on the customer's board, we have a chance at determining the problem. Once removed, determination of root cause drops to less than 5% success rate (as most problems are with the user's design, followed by their signal integrity, followed by solder problems). So, yes, we are interested in why production parts fail, but no, we are not interested in performing costly F/A on an ES part. We might actually request return of an ES part because we feel we may learn something (like develop a better production test), but that is pretty rare. Good question. Thanks for asking it so I can educate folks, Austin Eric Smith wrote: > austin wrote: >> As an example, ES parts are never accepted for a "RMA" (returned >> merchandise authorization) > > Makes perfect sense. > >> or for F/A (failure analysis). > > You guys don't want to determine why ES parts fail? That seems > really strange.Article: 125246
> Wine??? There are very, very few applications that actually work under Wine. > And of those, the majority is of no interest for Linux users, because there > are perfect alternatives which are native Linux. What.... are you smokin' You can run freaking World of Warcraft and PCAD in the ubuntu Wine's And while their are "alternatives" to those it doesn't really make a difference if you specifically want to play Warcraft or you company uses PCAD. NZGArticle: 125247
On Oct 18, 10:08 am, Philip Herzog <p...@arcor.de> wrote:
> jan.kindt wrote:
> > how about a big case statement ?
>
> Gets too big if the width grows, and doesn't work with generic widths... :(
>
> - Philip
> --
> Democracy: Three wolves and a sheep voting on what's
> for dinner.
What about:
process(one_hot)
variable temp : integer range 0 to 15;
begin
for k in one_hot'range loop
if one_hot(k) = '1' then
temp <= k;
end if;
end loop;
address <= to_unsigned(temp, 16);
end process;
Although I think the case statement approach probably synthesizes a
lot nicer, and is much nicer code. I'm pretty sure this will
synthesize, but I'd build a test module with small vectors first and
check the RTL viewer to make sure it turns into something that makes
sense.
Article: 125248Colin, A MAC+PHY costs more then a PHY, but you save the MAC IP cost and gates in the FPGA. It is a good alternative to consider. Xilinx has a MicroBlaze interface to this type of device, called the EPC. They also have an application note that describes how to use it: http://www.xilinx.com/bvdocs/appnotes/xapp924.pdf The app note uses a piece of hardware that is no longer available (Avnet P160 Comm 3 module), but you can look at the Spartan-3 Mini- Module which also has the 91C111 MAC+PHY. Bryan colin wrote: > Hi > > Does anyone have any experiences with connecting a MAC rather than a > PHY to a spartan(3e). > > I don't know yet whether to use a microblaze or my own state machine > to connect to the ethernet. For microblaze, xilinx cores seem to want > just an external PHY but surely a MAC would offload more stuff from > the FPGA. > > Any thoughts appreciated. > > Regards > > ColinArticle: 125249
We are using V5LX110T and V5L330 FPGAs. Are there decent pin swapping utilities so that we do not have to spend a lot of time in PCB Laout to do the pin swapping? I am hoping that the tool shows the BGA view of the FPGA and lets the user to swap pins such that there is good break out from the FPGA. Thanks. CP
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