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
Today I got this in Altera's email newsletter Get RoHS Compliant with Altera FPGAs, CPLDs and Structured ASICs I have never seen a single 3000 series PLD available in leadfree that you could actually purchase for delivery from stock. I have been able to buy lead versions of most of this family without too much trouble. I managed to buy a small number of leadfree Max II parts that are on allocation. I think the current delivery is something like 14 weeks (about when we are all supposed to be RoHS compliant). I guess I found this ad a bit ironic since we have all known that RoHS was coming for a long time and Altera is bragging in their ads that they have been shipping RoHS compliant devices for a long time. I guess this must not include their distributors...... I hate the RoHS requirements, but like nearly everyone else, we are working to comply. It doesn't help when the manufacturers are at least a year late in the transition process. Thanks for listening to my rant..... -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.comArticle: 96926
Al Clark wrote: > Today I got this in Altera's email newsletter > > Get RoHS Compliant with Altera FPGAs, CPLDs and Structured ASICs > > I have never seen a single 3000 series PLD available in leadfree that you > could actually purchase for delivery from stock. I have been able to buy > lead versions of most of this family without too much trouble. > > I managed to buy a small number of leadfree Max II parts that are on > allocation. > > I think the current delivery is something like 14 weeks (about when we are > all supposed to be RoHS compliant). > > I guess I found this ad a bit ironic since we have all known that RoHS was > coming for a long time and Altera is bragging in their ads that they have > been shipping RoHS compliant devices for a long time. I guess this must not > include their distributors...... > > I hate the RoHS requirements, but like nearly everyone else, we are working > to comply. It doesn't help when the manufacturers are at least a year late > in the transition process. > > Thanks for listening to my rant..... Think this is bad - just wait for the stock write-downs, as massive inventories of Lead based parts suddenly go past a 'use by' date... -jgArticle: 96927
Anyone familiar with the reasoning behind the lead restrictions? There hasn't been any publicity excepting the compounds that are poison when eaten and those that are poison in the blood stream. Are there others? Hul Al Clark <dsp@danvillesignal.com> wrote: > Today I got this in Altera's email newsletter > Get RoHS Compliant with Altera FPGAs, CPLDs and Structured ASICs > I have never seen a single 3000 series PLD available in leadfree that you > could actually purchase for delivery from stock. I have been able to buy > lead versions of most of this family without too much trouble. > I managed to buy a small number of leadfree Max II parts that are on > allocation. > I think the current delivery is something like 14 weeks (about when we are > all supposed to be RoHS compliant). > I guess I found this ad a bit ironic since we have all known that RoHS was > coming for a long time and Altera is bragging in their ads that they have > been shipping RoHS compliant devices for a long time. I guess this must not > include their distributors...... > I hate the RoHS requirements, but like nearly everyone else, we are working > to comply. It doesn't help when the manufacturers are at least a year late > in the transition process. > Thanks for listening to my rant..... > -- > Al Clark > Danville Signal Processing, Inc. > -------------------------------------------------------------------- > Purveyors of Fine DSP Hardware and other Cool Stuff > Available at http://www.danvillesignal.comArticle: 96928
Hello Allan. Check your email ;o) Bugs fixed are: - shift_bit was relying on the ALU result instead of the first operand. - port_id was always at the implied port value. I checked your bug report today, and I think I fixed it now. I will add the modifications to the release as soon as I finish testing it. Cheers. -- /"However, what if it does matter, and we are PabloBleyerKocik / missing something fundamental that could pablo / change the way we see the world?" @bleyer.org / -- One Little Wrong Assumption, Darren AshbyArticle: 96929
richard wrote:
> So, are any of you guys seeing the same sorts of problems? Doesn't it
> make sense to have a half-hour review of a schematic rather than a
> week-long review of a ream of HDL listings?
HDL code is optimized for simulation and synthesis.
It makes more sense to review the simulation waveforms.
because, for the right design rules, the waves will be
the same on the bench.
-- Mike Treseler
Article: 96930There is an older generation of designers (my generation) who grew up thinking in terms of the 7400 data book: 74161, 74138, etc create instant associations. But we must all realize: those designs were created between 1968 and 1971, i.e. more than 35 years ago, when designers at Fairchild (I was one of them) and T.I. defined practical logic blocks that fit into a 16-pin package, and could be interconnected with a minimum of extra "junk", like inverters. Those "rules of the games" have changed drastically. 16-pin packages have become 300- to 1400-pin packages, inverters have evaporated in the LUT structures... Apparently we did too good a job of indoctrinating the logic designers to think in terms of MSI functions. But remember, this was created for your father's or even grandfather's generation. 35 years is an eternity in this business. Keep thinking in terms of functionality, draw block diagrams, but leave the gory details to the synthesizers. R.I.P. 7400 ! Peter Alfke, Xilinx ApplicationsArticle: 96931
Hello,
I'm working on a project targeting a Lattice Mach4 CPLD using VHDL. In
the past I have never used the inout VHDL type, but with this design I
am forced to. When I use Synplicity to synthesize though I get fanout
errors for every bit in my inout signal:
Warning: network `cp20_main', node "PD_15_.BLIF" does not fanout
...
What exactly does this warning mean? I am hoping to use a single data
bus for both input and output, tri-stating the output when it isn't
used. Here is my latch that I'm using to output:
entity latch8 is
port(
clk:in std_logic;
rst:in std_logic;
data_in:in std_logic_vector(7 downto 0);
latch_enable:in std_logic;
output_enable:in std_logic;
data_out:out std_logic_vector(7 downto 0)); -- this drives an
inout in my top level
end latch8;
architecture bhv of latch8 is
signal data_latched: std_logic_vector(7 downto 0);
begin
process(clk,rst)
begin
if(rst='1') then
data_latched <= "00000000";
elsif(clk'event and clk='1') then
if(latch_enable='1') then
data_latched <= data_in;
end if;
end if;
end process;
data_out <= data_latched when output_enable='1' else
"ZZZZZZZZ";
end bhv;
Am I doing something wrong here??
Thank you for the help.
-- Shawn
Article: 96932
Peter Alfke wrote:
> There is an older generation of designers (my generation) who grew up
> thinking in terms of the 7400 data book: 74161, 74138, etc create
> instant associations.
Indeed. Some EE professors are still
teaching this abstraction level.
> Apparently we did too good a job of indoctrinating the logic designers
> to think in terms of MSI functions.
Yes. Even some of the newer generation
seem convinced that FPGAs are full of
little counters, shifters and adders
that just waiting to be wired up.
> Keep thinking in terms of functionality, draw block diagrams, but leave
> the gory details to the synthesizers. R.I.P. 7400 !
Well said.
Thanks for the posting.
-- Mike Treseler
Article: 96933They are shipping as we speak. There was a huge demand for it.Article: 96934
richard wrote: > So, are any of you guys seeing the same sorts of problems? Doesn't > it make sense to have a half-hour review of a schematic rather than a > week-long review of a ream of HDL listings? I was using schematic entry for as much of my design work as possible a year or two ago, much to my colleague's dismay! (I must admit, finding and placing bus joiners and creating new nets just to wire up a component that would be 2 lines of VHDL was beginning to annoy me.) However, since then I've been doing a lot more HDL work and have actually gone back and converted all my early schematics to VHDL! I'm now a "born-again" HDL'ian and find it so much quicker and more convenient to develop, maintain, re-use and *PORT* HDL code - not to mention source control is a lot nicer/easier now. My testbenches are all written in HDL as well now (mainly Verilog). FWIW, I'd never return to schematics. Yes, top level can be nice as Mike pointed out, but I find the disadvantages - slow, buggy tools, cumbersome maintenance, no portability - far outweigh the benefits. Regards, MarkArticle: 96935
Mark McDougall wrote: > richard wrote: > >> So, are any of you guys seeing the same sorts of problems? Doesn't >> it make sense to have a half-hour review of a schematic rather than a >> week-long review of a ream of HDL listings? > > > I was using schematic entry for as much of my design work as possible a > year or two ago, much to my colleague's dismay! > > (I must admit, finding and placing bus joiners and creating new nets > just to wire up a component that would be 2 lines of VHDL was beginning > to annoy me.) > > However, since then I've been doing a lot more HDL work and have > actually gone back and converted all my early schematics to VHDL! I'm > now a "born-again" HDL'ian and find it so much quicker and more > convenient to develop, maintain, re-use and *PORT* HDL code - not to > mention source control is a lot nicer/easier now. My testbenches are all > written in HDL as well now (mainly Verilog). > > FWIW, I'd never return to schematics. Yes, top level can be nice as Mike > pointed out, but I find the disadvantages - slow, buggy tools, > cumbersome maintenance, no portability - far outweigh the benefits. > > Regards, > Mark If you could watch the operation of the circuits inside your prototyping board directly on your schematics as they run in real-time, or clock by clock would you find this useful?Article: 96936
I have used sysgen to build a model with microblaze, but i don't know the difference between the two functions: microblaze_nbwrite_datafsl and microblaze_bwrite_datafsl. Will the later function stop the microblaze until finishing writing operation? thanks. moreover, can i debug my c source code of microblaze in sysgen? if so, how?Article: 96937
I am simulating an EDK MicroBlaze embedded system using NC-Sim. Whenever I open a waveform window and try to simulate I get errors. Here they are: ncsim: *E,SST2ER: SST2 interface error: Permission denied. ncsim: *E,NOSHMO: cannot open SHM database file 'waves.shm'. So it seems I cannot create or modify a database. However, the simulation will run and display waveforms. Here is the script I am running to compile/elaborate/call the sim: # Compile testbench and project netlist sh system.sh #compile the testfixture ncvlog -update -work work testfixture.v # Elaborate ncelab -update testfixture glbl -timescale 1ns/1ns -access +RWC # Launch the simulator ncsim -gui testfixture:v As you can see, I have the acess set to +RWC, which should give me all the permission I need. I do NOT know what this is affecting really. My next problem is that it takes our system ~18,000,000,000ps to run all the initialization stuff. I don't care about any of this. I really would like to START simulating after all the init. Is there a way to do this? I know you can save a "Checkpoint", but I think I am having trouble doing so because of the previous errors. Thanks!!Article: 96938
Andrew Ward wrote: > > If you could watch the operation of the circuits inside your prototyping > board directly on your schematics as they run in real-time, or clock by > clock would you find this useful? I worked with some tools way back when that had this capability - I think Mentor quicksim/design architect IIRC - or maybe it was Daisy. I found it to be not really that useful. You really need to see waveforms to make sense of what is going on. Speaking of schematic editors, Mentor's Design Architect was a fantastic editor. The "stroke commands" were genius. Hold the middle mouse button in and draw little free-hand "glyphs" that would disappear when you released the button as a way to invoke common commands like select, copy, move, delete etc. -JeffArticle: 96939
Jeff Cunningham wrote: > Andrew Ward wrote: > >> >> If you could watch the operation of the circuits inside your >> prototyping board directly on your schematics as they run in >> real-time, or clock by clock would you find this useful? > > > I worked with some tools way back when that had this capability - I > think Mentor quicksim/design architect IIRC - or maybe it was Daisy. I > found it to be not really that useful. You really need to see waveforms > to make sense of what is going on. > Yes that is what our product does, you can see the values directly on components, and as waveforms as well. Best of both worlds, only it is not a simulator, what you see is what's going on in the hardware. Here is a picture of what I mean: http://www.hevday.com/operation_pictures.html If you look at the bottom of this page there is a picture of our long time scale waveform view. With this you can watch for spikes etc. over days of real time. Can you do that with your simulator? > Speaking of schematic editors, Mentor's Design Architect was a fantastic > editor. The "stroke commands" were genius. Hold the middle mouse button > in and draw little free-hand "glyphs" that would disappear when you > released the button as a way to invoke common commands like select, > copy, move, delete etc. > > -JeffArticle: 96940
I'm not sure what you mean. Lead is a heavy metal that causes many problems including permanent damage to the central nervous system. That is why lead is no longer in gasoline or paint. The lead in electronics ends up in landfills which at some point will end up in our water and food chain. Yes, we take great "precautions" to keep landfills intact and away from our water sources, but they all leak and some leak a lot. Eventually they will all be sources of significant contamination of our environment if they contain long term polutants like lead. That is it in a nutshell. If we continue to concentrate dangerous polutants by putting them in products and then bury them in our back yards, we will never have an even remotely clean environment. Hul Tytus wrote: > Anyone familiar with the reasoning behind the lead restrictions? There > hasn't been any publicity excepting the compounds that are poison when > eaten and those that are poison in the blood stream. Are there others? > > Hul > > Al Clark <dsp@danvillesignal.com> wrote: > > Today I got this in Altera's email newsletter > > > Get RoHS Compliant with Altera FPGAs, CPLDs and Structured ASICs > > > I have never seen a single 3000 series PLD available in leadfree that you > > could actually purchase for delivery from stock. I have been able to buy > > lead versions of most of this family without too much trouble. > > > I managed to buy a small number of leadfree Max II parts that are on > > allocation. > > > I think the current delivery is something like 14 weeks (about when we are > > all supposed to be RoHS compliant). > > > I guess I found this ad a bit ironic since we have all known that RoHS was > > coming for a long time and Altera is bragging in their ads that they have > > been shipping RoHS compliant devices for a long time. I guess this must not > > include their distributors...... > > > I hate the RoHS requirements, but like nearly everyone else, we are working > > to comply. It doesn't help when the manufacturers are at least a year late > > in the transition process. > > > Thanks for listening to my rant..... > > > > > -- > > Al Clark > > Danville Signal Processing, Inc. > > -------------------------------------------------------------------- > > Purveyors of Fine DSP Hardware and other Cool Stuff > > Available at http://www.danvillesignal.comArticle: 96941
elf_ster@hotmail.com writes: > They are shipping as we speak. There was a huge demand for it. The Xilinx Online Store *STILL* says "Notify me when available", and I requested that notification many months ago. Since they haven't been taking orders for them, to whom are they shipping them?Article: 96942
I have a working prototype board from yesteryear with a Flex 10K100GC503-3 FPGA and an EPC2L120 configuration device on it. I realize these are geriatric parts by todays standards, but if I can get this board working, it will do what I need. Altera is no help - pointing out that the part was EOL'ed in 1993. This board definitely worked when it was put into storage, though I used an older copy of MaxPlusII to program it at the time. I created the EDIF files then using Synplicity 7.2.3. At that time, I had no problem either programming the FPGA directly with the .sof or the EPC2 with the .pof. The JTAG chain is ridiculously simple, correctly pulled up / terminated, and on a quality 4-layer board. We followed the app note on adding a byteblaster port to a 'T'. Now, for some reason, I am having intermittent problems programming both devices. I am on a newer class machine (Pentium 4 vs Pentium III), and I am attempting to use the free Quartus Webpack instead of MaxPlusII - which, while it has a "free" license, doesn't include Flex 10K support. I can manually specify the correct part in the Quartus .qsf file, and the tool even correctly identifies the pins in the device settings. (note - you can get "indirect" support for a lot of older parts this way - Quartus just doesn't advertise them) Other than a slight problem using conf_done as a general purpose I/O pin, it seems to all be working. I have generated test applications that correctly exercise the LEDs, switches and GPIO. The problem is that when I try to download the bitstream, the programmer gets between 50 and 79% done and errors out, reporting that device 1 (the FPGA) CONF_DONE pin did not go high. Sometimes, though, it will download correctly - and that is what is maddening. If it didn't work at all, I would understand. More interesting, once it DOES configure correctly once, it seems to work properly until I power down the board. Likewise, the EPC2 works sometimes, and fails others. I believe the byteblaster is good, even if I did build it myself (I followed the Altera ByteBlasterMV schematic faithfully) so I'm not sure what could be causing this. Ironically, I did borrow a "real" ByteBlasterMV with the *worse* results. I have checked all the wiring in my byteblaster box, and it checks out. The power supply voltages are spot on (5.04V for the FPGA, 3.34V for the I/O buffers). My byteblaster has an LED indicator that shows when the '244 is being driven, and I am definitely seeing activity. Lastly, I have noticed that simple designs seem to download more reliably than larger designs. Not sure why, as the programming file should be of equal length either way (though there may be a lot of zero padding in the smaller files) Is there something I need to adjust in my PC's BIOS, Quartus, elsewhere? Any help greatly appreciated!Article: 96943
Has anyone altered the I2C core by Xilinx to sample on the posedge rather than negedge. I am interfacing with the microcontroller and the negedge is actually very slow around 200ns because of which a counter bitcnt sometimes increments twice and this leads to problems in the exact transfer of data. It would be nice to know if someone has tried to change the sampling from negedge to posedge. As you can infer I havent actually gone through the entire core. As well I was wondering whether there is any alternative to this problem. I have read most of the threads about schmitt triggers. but then since this is a bidirectional bus it is not possible to use schmitt triggers i think. as well tried the xilinx app note for schmitt triggers which says something about resistors. but having problems inverting the scl line and getting it out through another port. Thanks RegardsArticle: 96944
> Have you ruled out software analyzers? Yes i did. SW USB analyser are great & useful ! Some are free (SniffUsb) some are not (SourceUsb) However, under Windows anyway, USB SW analyzer hides part of the low level stuff , they allow to see URBs requests which is already relevant but sometimes not enough. Another reason why i look ahead for HW analyser is that i aim at developping USB device and/or controller with an FPGA.....Article: 96945
Hi All, I was wondering if anyone has declared an entity with multiple architectures using Xilinx ISE. How is this done, whether both architectures are defined in the same file where the entity is declared. Thanks in advance SudhirArticle: 96946
svasus@gmail.com wrote: > Has anyone altered the I2C core by Xilinx to sample on the posedge > rather than negedge. I am interfacing with the microcontroller and the > negedge is actually very slow around 200ns because of which a counter > bitcnt sometimes increments twice and this leads to problems in the > exact transfer of data. It would be nice to know if someone has tried > to change the sampling from negedge to posedge. As you can infer I > havent actually gone through the entire core. > > As well I was wondering whether there is any alternative to this > problem. I have read most of the threads about schmitt triggers. but > then since this is a bidirectional bus it is not possible to use > schmitt triggers i think. What you can do is drive both lines OpenDrain, and feed both lines via schmitt triggers, into two more pins, SDAf and SCLf, and THOSE are the ones read by the Logic. ie separate PINS for DRIVE and Listen That way, the problems of double clocking on slow edges is avoided. FPGAs are so fast, the relatively slow rise times of busses like i2c can cause problems.... -jgArticle: 96947
Hi, My first results are here : http://osainto.free.fr/usb/USB%20Trafic%20Capture.html Not very easy to identify the SYNC bits , and the SOF.... The en dof packet is easier ( Both D+ & D- at '0') Note that sample time of used logci anlyser is 10 ns .... "Jerome" <nospam@nospam.com> wrote in message news:43f169ea$0$379$636a55ce@news.free.fr... >> Have you ruled out software analyzers? > > Yes i did. > SW USB analyser are great & useful ! > Some are free (SniffUsb) some are not (SourceUsb) > > However, under Windows anyway, USB SW analyzer hides part of the low level > stuff , they allow to see URBs > requests which is already relevant but sometimes not enough. > > Another reason why i look ahead for HW analyser is that i aim at > developping USB device and/or controller with an FPGA..... > > > >Article: 96948
elf_ster@hotmail.com wrote: > They are shipping as we speak. There was a huge demand for it. Huh? Who? What? Uh... Where from? I've been looking at the Xilinx Online Store and the digilentinc site and have seen nothing. The only order entry I've seen was from distribution and I didn't trust it to do any better than the first two sources. I'm talking 3e starter kit, not the sample pack.Article: 96949
svasus@gmail.com wrote: > Has anyone altered the I2C core by Xilinx to sample on the posedge > rather than negedge. I am interfacing with the microcontroller and the > negedge is actually very slow around 200ns because of which a counter > bitcnt sometimes increments twice and this leads to problems in the > exact transfer of data. It would be nice to know if someone has tried > to change the sampling from negedge to posedge. As you can infer I > havent actually gone through the entire core. > > As well I was wondering whether there is any alternative to this > problem. I have read most of the threads about schmitt triggers. but > then since this is a bidirectional bus it is not possible to use > schmitt triggers i think. as well tried the xilinx app note for schmitt > triggers which says something about resistors. but having problems > inverting the scl line and getting it out through another port. > > > Thanks > > Regards I haven't seen the core but I was reimplementing an I2C interface recently. The I2C electrical specs have a glitch tolerance spec for data *and* clock which would mean that sampling the data directly with an edge isn't recommended by the spec. If you use a higher-rate clock to sample both the clock and data, implementing a glitch filter is pretty straight forward.
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