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
On Feb 12, 12:03=A0pm, Jon Elson <el...@wustl.edu> wrote: > DJ Delorie wrote: > > Not much compared to the "norm" around here, but... > > >http://www.delorie.com/electronics/bin2seven/ > > Aughhh! =A0Isn't there a better way to do the binary to BCD conversion? > Not that there'd be any difference in performance or area, just that the > brute-force enumeration of all possible states seems ugly. =A0I'd hate to > do this for a 12-bit or wider conversion. > > Jon A 256x10 ROM is pretty clean if it implements in a BlockRAM. If it goes to distributed logic, I'd suggest a Binary to BCD conversion such as that covered in http://www.xilinx.com/support/documentation/application_n= otes/xapp029.pdf (a reasonably-sized url - WooHoo!) coauthored back around `97 by our own Peter Alfke. In those days I was just starting to venture out from the schematic realm into HDLs. I used the app note to get my head around the simpler conversion technique that I ended up implementing as a function in a picoBlaze LCD display driver recently. Clean. - John_HArticle: 129001
On Feb 12, 12:40=A0pm, Andy Botterill <a...@plymouth2.demon.co.uk> wrote: <snip> > > Why do you want to do this? Why does someone want to crash their car? It's quite apparent this was an accident.Article: 129002
Hi all, This is somewhat OT, but I am not sure where to ask... In a V4FX based system I need to come up with a way of having 2 ethernet connections to a backplane. The original plan was to use two TEMACs, each connected to an individual PHY. However, the device got pretty full and it is difficult now to add the support for the second TEMAC. Besides, it seems that all we really need is to be able to switch between two ethernets on backplane. So, either I need to be able to switch between two PHYs at the RGMII level, or just have one PHY and switch at the ethernet PHY level. I was wondering what people normally do and what components are known to be good for this sort of thing. I need to support 10/100/1000 modes. Thanks, /MikhailArticle: 129003
On Feb 12, 3:46 pm, John_H <newsgr...@johnhandwork.com> wrote: > On Feb 12, 12:40 pm, Andy Botterill <a...@plymouth2.demon.co.uk> > wrote: > <snip> > > > > > Why do you want to do this? > > Why does someone want to crash their car? It's quite apparent this > was an accident. It was an "accident" in that the 1.2v supply/regulator was wrong and was generating 2.5v instead. Hence the question. :)Article: 129004
Jon Elson wrote: > > > DJ Delorie wrote: > >> Not much compared to the "norm" around here, but... >> >> http://www.delorie.com/electronics/bin2seven/ > > > Aughhh! Isn't there a better way to do the binary to BCD conversion? > Not that there'd be any difference in performance or area, just that the > brute-force enumeration of all possible states seems ugly. I'd hate to > do this for a 12-bit or wider conversion. Perhaps using the Divide and Modulus operators ? -jgArticle: 129005
On 2008-02-12, Vagant <vladimir.v.korostelev@rambler.ru> wrote: > Visual Basic) and FPGA-board. A port for communication will be RS232 > and I want to get my scope working under Windows XP. What you think, > is writing a driver necessary for such system? (Unfortunately, I have > no experience with writing drivers.) What you are calling a driver already exists in the system. Something is provided by the operating system to talk to the UART in your PC. You get an interface that can exchange bytes. You have to develop your own protocol on top of that. If you had a USB chip on the FPGA board, you'd use a driver provided by the FPGA vendor. The interface might still look exactly the same (if you use it as a USB UART) or you might use some custom interaction based on an API provided by the USB chip maker (eg FTDI). -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 129006
Good Afternoon- I posted this to comp.dsp the other day but had someone suggest I post it here. I'm interested in learning more about DSP's and actually getting my feet wet with DSP hardware. I have three primary interests: 1) robotics 2) computer vision 3) software defined radios. My original intent was to keep working with Atmel AVR's in robotics and not learn more about FPGA's until the time for #2 and #3 arose, however, the more I read, the more I keep hearing about things like open cores and Xilinx's FireBlaze processor simulation on a FPGA. I'm wondering if it would be more practical to build robotics around the FPGA from square one and start learning now. It seems like you can do just about anything with FPGA's (with some tradeoffs of course) My second question is, what is the best way to start learning? In doing reading I see the Spartan 3E evaluation board seems to be highly recommended. The board looks neat, I'm just curious what the best way to learn is. I'm doing this as a hobby, I'm a mechanical engineer by trade. I've been programming C/C++ for 10 years and I've taken a few basic EE courses, (both analog circuits and basic digital logic) so as some would say, "I know enough to be dangerous". :) Thanks for the thought, PhilipArticle: 129007
I think I've found a solution: http://www.pericom.com/products/switch/assp/family.php?familyID=12 /Mikhail "MM" <mbmsv@yahoo.com> wrote in message news:61ef5fF1tqri7U1@mid.individual.net... > Hi all, > > This is somewhat OT, but I am not sure where to ask... In a V4FX based > system I need to come up with a way of having 2 ethernet connections to a > backplane. The original plan was to use two TEMACs, each connected to an > individual PHY. However, the device got pretty full and it is difficult > now to add the support for the second TEMAC. Besides, it seems that all we > really need is to be able to switch between two ethernets on backplane. > So, either I need to be able to switch between two PHYs at the RGMII > level, or just have one PHY and switch at the ethernet PHY level. I was > wondering what people normally do and what components are known to be good > for this sort of thing. I need to support 10/100/1000 modes. > > Thanks, > /Mikhail > >Article: 129008
Jon Elson <elson@wustl.edu> writes: > Aughhh! Isn't there a better way to do the binary to BCD conversion? > Not that there'd be any difference in performance or area, just that > the brute-force enumeration of all possible states seems ugly. It was pointed out elsewhere that it can be done like this: 214 : bcd <= 10'h214 ; 215 : bcd <= 10'h215 ; etc, then split out the three digits later. Still a big table, but not as ugly. The div/mod operators were mentioned too, but I haven't had a chance to try those and see what ISE thinks of them. In my case, I have a perl script that generates that huge table anyway.Article: 129009
On Wed, 13 Feb 2008 00:24:54 +0800, Nick <tklau@cuhk.edu.hk> wrote:
>I am trying to write and read registers from a CMOS sensor via I2C. The
>SCLK and SDATA pins are pulled by 3.3V and are connected to two I/O pins
>on Spartan3 FPGA.
>
>When the FPGA is reading from SDATA, would it be always high ('1' bit
>instead of '0') as it's pulled up??
Yes, provided you do all the right things:
(1) Make sure that your FPGA doesn't drive SDATA when disabled.
(2) Ensure that there is a pullup resistor of appropriate value
somewhere on the SDATA bus.
VHDL:
port ...
SDATA: inout std_logic;
...
--- Park this signal at '1' when you don't want to drive SDATA.
signal internal_SDATA_drive: std_logic;
-- Use this signal as input to your SDATA receiver logic:
signal internal_SDATA_rcv: std_logic;
...
SDATA <= '0' when internal_SDATA_drive = '1' else 'Z';
internal_SDATA_rcv <= to_X01(SDATA);
A couple of notes here:
- the to_X01() strength-stripper function is useful if you
wish to *simulate* the external pullup resistor by applying
an external driver to the SDATA bus:
SDATA <= 'H';
because it causes the H value to translate to '1'
on the internal signal;
- you're relying on the pullup resistor to take the bus high
when you try to drive a '1'; there are ways around this
(very briefly drive the bus to '1' when your internal
signal transitions from 0 to 1) to avoid the slow rising
edges associated with pullups.
In Verilog:
module I2C_thing( inout SDATA, ...);
wire internal_SDATA_drive, internal_SDATA_rcv;
assign SDATA = internal_SDATA_drive? 1'bz : 1'b0;
assign internal_SDATA_rcv = SDATA;
and, in simulation, use the pullup primitive on SDATA:
pullup (SDATA);
HTH
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 129010>...what is the best way to start learning? In >...I'm just curious what the best way to learn is. > > I'm doing this as a hobby...a mechanical engineer by trade. >I've been programming C/C++ for 10 years... >"I know enough to be dangerous". :) There's no "royal road" to learning. If you're a genius then you can maybe learn just by reading textbooks. For the rest of us, just start anywhere and see where it takes you. Doing this as a hobby gives you the luxury of taking any road you fancy, but omits the discipline of a goal you can't change. My own preference is for that unyielding target, but that may not be best for everyone. If you're very rich then send yourself on training courses, but you'll still have to put in hard work and late nights to become competent. The first step to that competence is knowing that you know enough to be dangerous. This puts you ahead of many who, after ten years of "professional" work don't realise that they're still dangerous. MikeArticle: 129011
<everphilski@gmail.com> wrote in message news:80dca10c-c80d-4fa2-9ed5-0ba73bc161fa@s37g2000prg.googlegroups.com... > > I'm wondering if it would be more practical to build robotics around the > FPGA from square one and start learning now. It seems like you can do > just about anything with FPGA's (with some tradeoffs of course) I think it depends on whether your goal is to build a robot or to learn something completely new and not much related to robots. Yes, you can do many different things with FPGAs, but if you want to build a robot soon choose the path you already know... /MikhailArticle: 129012
Sometimes a long path is not really a long path. For example the output of the combinational logic (between two registered) is not really used on the next clock cycle but perhaps two or more cycles later. In such a case it doesn't really matter if the output didn't stabilize the next clock cycle because it takes one or more cycles before it's actually used. Adding a multi-cycle path constraint fixes this issue and informs the tool that it needn't constraint that path delay within one cycle time. False paths also are another similar issue though I personally did not run into them before. I think proper analysis of the offending paths is mandatory before a solution can be proposed. On Feb 8, 7:46 pm, morphiend <morphi...@gmail.com> wrote: > On Feb 8, 11:05 am, Mike Treseler <mike_trese...@comcast.net> wrote: > > > Clemens wrote: > > > I put a timing constraint in the UCF File where i asked for a minimum > > > frequency of 35 MHz (29 ns) but unfortuatenly XST tells me that > > > the ratio was not met and the actual ratio is 38 ns. I have already > > > optimized for speed, it there any way to tell the tool it should > > > sythesis it for more than 35 MHz forgetting about any area constraints? > > > It sounds like synthesis has done its best. > > I would find the slow nets and pipeline them. > > > -- Mike Treseler > > There are other things that can be done. > > One of the first ones is to use the Timing Analyzer from ISE. This > tool will give you some good ideas to try and make your design work. > It will also let you see exactly how you're failing the timing on that > clock. > > Another option is to try multi-pass map/place-and-route. I say both > because as of the 9.1 version of the tools, you have to perform MAP > and PAR at the same cost-table value for it to work as expected. If > you're solely using ISE, this can be enabled from one of the menu's, > somewhere. I do most of my work in EDK and I have a script that I use > to perform multi-pass place and route. If you're interested, I could > post it. > > Another option that was introduced in the 9.1 version of the ISE tools > is called the xplorer script. This is a more advanced version of multi- > pass place and route (aka mppr). Previously, mppr just changed the > cost table value and as such the placing of the design was affected. > Now with the new xplorer script, it not only performs cost table > changes, but trying advanced options for different types of algorithms > for specific problems. > > Odds are using timing analyzer is all you need to do, and hopefully > won't need to start worrying about mppr or xplorer yet. Those are > usually used when trying to achieve higher frequencies than the one > you mentioned (>100MHz fabric speeds). > > -- MikeArticle: 129013
I haven't done it on your specific model of FPGA, but for the Virtex-II Pro and above you can repurpose the USB programming JTAG port for data communications. Look into the BSCAN primitive. To make a GUI, all you have to do is do a simple TCL/TK script. ---Matthew Hicks > On 12 ???, 20:30, John_H <newsgr...@johnhandwork.com> wrote: > >> On Feb 12, 9:27 am, Vagant <vladimir.v.koroste...@rambler.ru> wrote: >> >>> Hello, >>> >>> I want to design FPGA-based PC oscilloscope controlled by a user of >>> the PC. I am not sure how to provide communication between PC based >>> application (a main program on PC; this will be written either in C >>> or Visual Basic) and FPGA-board. A port for communication will be >>> RS232 and I want to get my scope working under Windows XP. What you >>> think, is writing a driver necessary for such system? >>> (Unfortunately, I have no experience with writing drivers.) >>> >> This is the problem with modern-day systems; it's software and >> hardware, both. >> >> If you want to give a bad customer interface, then sure - use the >> serial port and you can probably call up simple communication >> routines on the PC for the software devolopment you still need to do. >> >> To do it right, you really should consider USB (or even ethernet) and >> go through the hassle of developing a real driver. The speed and >> integration are so much better. >> >> - John_H >> > I would like to use USB for communication but a USB interface of my > board (Spartan3E-1600E Microblaze Development Kit) can be used only to > download design, not for communication. So I might think about using > Ethernet for my project, but I don't know even where to start with > this. Would you recommend any source of information about using > Ethernet with FPGA for a beginner? >Article: 129014
Hi Dave,
my mistake. Here is what i intended it to be.
to paraphrase:
#1: RTS(PC) -> CTS(FPGA) 0 =3D PC has no data to send to FPGA. If PC
sends data without asserting its RTS,
UART will not shift
in the inputs.
1=3D PC should assert this
if it has data to send. only then can FPGA can receive data
from PC
#2: RTS(FPGA) -> CTS(PC) 0 =3D receive buffer on UART attached to
microblaze is full. During this time, PC should
no longer transmit
to FPGA. once receive buffer has been cleared, FPGA will set
the RTS line again.
1 =3D PC can transmit to
FPGA as the UART receive buffer is not full.
did you spot any mistake? Is there a need for FPGA to use DSR?
Chris
On Feb 12, 11:47=A0pm, Dave Pollum <vze24...@verizon.net> wrote:
> On Feb 11, 10:55 am, chrisde...@gmail.com wrote:
> <snip>
> 1) rts on PC side will drive FPGA cts pin. If rts on PC side =3D 1, then
> transmission =A0from FPGA to PC will be possible. otherwise, the FPGA
> cannot transmit anything back to PC.
> 2) cts on PC side is driven by FPGA rts pin. FPGA rts pin =3D 1 once the
> receiver buffer in UART peripheral attached to microblaze is full.
> this will disable PC from sending any more data to microblaze on the
> FPGA.
> <snip>
>
> to paraphrase:
> #1: RTS(PC) =A0 -> CTS(FPGA) =A01 =3D FPGA transmits to PC
> #2: RTS(FPGA) -> CTS(PC) =A0 =A01 =3D PC _does not_ transmit to FPGA
>
> Is this really what happens, or did you mistype?
> -Dave Pollum
Article: 129015everphilski@gmail.com <everphilski@gmail.com> wrote: > I'm interested in learning more about DSP's and actually getting my > feet wet with DSP hardware. I have three primary interests: > 1) robotics For robotics I think you're better off in the microcontroller realm, with something like your Amtel AVR or a Parallax Propeller that will easily interface with all kinds of easily available and relatively inexpensive modules (www.sparkfun.com kinda stuff). I think of robotics more as a system integration problem. > 2) computer vision Machine vision is pretty much entirely a software issue I think, so if you want to learn about it, I'd consider starting with a PC and a $20 webcam and the free programming language of your choice along with a book or two on the subject. Learning how to design a solution and implementing that solution in something like an FPGA are probably quite different tasks, and I'd be afraid of drowning in the details of implementation while trying to learn how to design what you want. > 3) software defined radios. For SDR maybe some DSP hardware (or FPGA maybe, though I'm not sure how much fun doing serious DSP in a Spartan 3 would really be) probably makes sense. I think there might be a few reasonably priced experimenter's boards out there. > My second question is, what is the best way to start learning? In > doing reading I see the Spartan 3E evaluation board seems to be highly > recommended. The board looks neat, I'm just curious what the best way > to learn is. The Spartan 3 starter board is fine (I have one), but to get started and get a feel for things you can start by downloading the free ISE WebPack software from Xilinx to see what the development process looks like for their FPGAs. You can design/code, build and simulate all without actually having any actual hardware. FPGAs are pretty cool, especially the "hardware becomes software" aspect which is quite appealing to those of us with more of a software background, but they're also very complex so if you're really interested in learning to design for FPGAs (programming in VHDL/Verilog etc.) then great, but if you're more interested in the applications than in the technology then something less generic and more specific to the problem you're trying to solve might greatly simplify things. Just my random thoughts. G.Article: 129016
On Feb 10, 7:25 pm, chrisde...@gmail.com wrote: > On Feb 9, 10:46 am, morphiend <morphi...@gmail.com> wrote: > > > > > On Feb 8, 11:05 am, Mike Treseler <mike_trese...@comcast.net> wrote: > > > > Clemens wrote: > > > > I put a timing constraint in the UCF File where i asked for a minimum > > > > frequency of 35 MHz (29 ns) but unfortuatenly XST tells me that > > > > the ratio was not met and the actual ratio is 38 ns. I have already > > > > optimized for speed, it there any way to tell the tool it should > > > > sythesis it for more than 35 MHz forgetting about any area constraints? > > > > It sounds like synthesis has done its best. > > > I would find the slow nets and pipeline them. > > > > -- Mike Treseler > > > There are other things that can be done. > > > One of the first ones is to use the Timing Analyzer from ISE. This > > tool will give you some good ideas to try and make your design work. > > It will also let you see exactly how you're failing the timing on that > > clock. > > > Another option is to try multi-pass map/place-and-route. I say both > > because as of the 9.1 version of the tools, you have to perform MAP > > and PAR at the same cost-table value for it to work as expected. If > > you're solely using ISE, this can be enabled from one of the menu's, > > somewhere. I do most of my work in EDK and I have a script that I use > > to perform multi-pass place and route. If you're interested, I could > > post it. > > > Another option that was introduced in the 9.1 version of the ISE tools > > is called the xplorer script. This is a more advanced version of multi- > > pass place and route (aka mppr). Previously, mppr just changed the > > cost table value and as such the placing of the design was affected. > > Now with the new xplorer script, it not only performs cost table > > changes, but trying advanced options for different types of algorithms > > for specific problems. > > > Odds are using timing analyzer is all you need to do, and hopefully > > won't need to start worrying about mppr or xplorer yet. Those are > > usually used when trying to achieve higher frequencies than the one > > you mentioned (>100MHz fabric speeds). > > > -- Mike > > Hi Mike, > Possible to post the mppr and xplorer script? thanks in advance! > > Chris The mppr script that I wrote and have used under EDK 9.1 and 9.2 is available here: http://www.eklipse.net/xilinx/ . It's called run_mppr. I don't have a xplorer script because it's part of ISE 9.1. I haven't used it either, so I'm not much of a help there. To use the script, run it from the root of your EDK project by run_mppr <system.mhs> <initial cost table value> <last cost table value> Once a PAR finishes successfully, it will stop iterating and print out that it finished. It also saves all the previous attempts, in case you want review them to see what the output was at each iteration.Article: 129017
Hi, Does any one know any examples on the xilinx web site or in the CD (which is sent with the starter kit) that can be downloaded to development board. If someone can help me on this, it would be great. I have received my board from Xilinx, i did find one example on the website, but that is for another fpga, and the fpga i am having in my board is XC3S700A. Can anyone help me on this. Regards, Anas.Article: 129018
On Feb 13, 8:30=A0am, Duane Clark <junkm...@junkmail.com> wrote: > > Well, I will have to admit that it has been several years since I have > done post place and route simulation. I really don't see much need for > that in FPGA design. ooo now thats a little scary BobsterthelobsterArticle: 129019
There are quite a few at: http://www.xilinx.com/products/boards/s3astarter/reference_designs.htm Eric "anas_waris" <anas_waris@hotmail.com> wrote in message news:704c96b0-93b6-4417-88c3-d89ab7f87eaf@z17g2000hsg.googlegroups.com... > Hi, > > Does any one know any examples on the xilinx web site or in the CD > (which is sent with the starter kit) that can be downloaded to > development board. If someone can help me on this, it would be great. > I have received my board from Xilinx, i did find one example on the > website, but that is for another fpga, and the fpga i am having in my > board is XC3S700A. Can anyone help me on this. > > Regards, > Anas.Article: 129020
anas_waris <anas_waris@hotmail.com> wrote: > Does any one know any examples on the xilinx web site or in the CD > (which is sent with the starter kit) that can be downloaded to > development board. If someone can help me on this, it would be great. > I have received my board from Xilinx, i did find one example on the > website, but that is for another fpga, and the fpga i am having in my > board is XC3S700A. Can anyone help me on this. Isn't this what you want? http://www.xilinx.com/products/boards/s3astarter/reference_designs.htm G.Article: 129021
Thanks for your detailed explanation!
I assign the SDATA to 'Z' in order to receive data, but the pin is
pulled up so I am wondering if the SDATA will read '1' regardless of the
actual incoming value.
Nick
Jonathan Bromley wrote:
> On Wed, 13 Feb 2008 00:24:54 +0800, Nick <tklau@cuhk.edu.hk> wrote:
>
>> I am trying to write and read registers from a CMOS sensor via I2C. The
>> SCLK and SDATA pins are pulled by 3.3V and are connected to two I/O pins
>> on Spartan3 FPGA.
>>
>> When the FPGA is reading from SDATA, would it be always high ('1' bit
>> instead of '0') as it's pulled up??
>
> Yes, provided you do all the right things:
> (1) Make sure that your FPGA doesn't drive SDATA when disabled.
> (2) Ensure that there is a pullup resistor of appropriate value
> somewhere on the SDATA bus.
>
> VHDL:
> port ...
> SDATA: inout std_logic;
> ...
>
> --- Park this signal at '1' when you don't want to drive SDATA.
> signal internal_SDATA_drive: std_logic;
>
> -- Use this signal as input to your SDATA receiver logic:
> signal internal_SDATA_rcv: std_logic;
>
> ...
> SDATA <= '0' when internal_SDATA_drive = '1' else 'Z';
> internal_SDATA_rcv <= to_X01(SDATA);
>
> A couple of notes here:
> - the to_X01() strength-stripper function is useful if you
> wish to *simulate* the external pullup resistor by applying
> an external driver to the SDATA bus:
> SDATA <= 'H';
> because it causes the H value to translate to '1'
> on the internal signal;
> - you're relying on the pullup resistor to take the bus high
> when you try to drive a '1'; there are ways around this
> (very briefly drive the bus to '1' when your internal
> signal transitions from 0 to 1) to avoid the slow rising
> edges associated with pullups.
>
> In Verilog:
>
> module I2C_thing( inout SDATA, ...);
> wire internal_SDATA_drive, internal_SDATA_rcv;
>
> assign SDATA = internal_SDATA_drive? 1'bz : 1'b0;
> assign internal_SDATA_rcv = SDATA;
>
> and, in simulation, use the pullup primitive on SDATA:
>
> pullup (SDATA);
>
> HTH
Article: 129022Don't try it. XST will complain that the second operand of DIV and MOD operators have to be powers of two, atleast, in the webpack version. I ran your code and the below code through the Cadence HDL-ICE synthesizer. (For Emulation only) The case statement was mapped to 188 cells in thier library, the DIV/MOD mapped to 92 cells. (AND02,OR02,XOR02,INV,etc.) But since this code doesn't work in the free ISE it doesn't matter. module bcd(ibin, bcd2,bcd1,bcd0); input [7:0] ibin; output[3:0] bcd2, bcd1, bcd0; wire [7 : 0] temp [0:1]; assign temp[0] = ibin/4'd10; assign bcd0 = ibin%4'd10; assign temp[1]= temp[0]/4'd10; assign bcd1 = temp[0]%4'd10; assign bcd2 = temp[1]%4'd10; endmodule "DJ Delorie" <dj@delorie.com> wrote in message news:xnfxvxesqn.fsf@delorie.com... > > Jon Elson <elson@wustl.edu> writes: >> Aughhh! Isn't there a better way to do the binary to BCD conversion? >> Not that there'd be any difference in performance or area, just that >> the brute-force enumeration of all possible states seems ugly. > > It was pointed out elsewhere that it can be done like this: > > 214 : bcd <= 10'h214 ; > 215 : bcd <= 10'h215 ; > > etc, then split out the three digits later. Still a big table, but > not as ugly. The div/mod operators were mentioned too, but I haven't > had a chance to try those and see what ISE thinks of them. > > In my case, I have a perl script that generates that huge table > anyway.Article: 129023
On 11 Feb., 15:29, paragon.j...@gmail.com wrote: > Also, does know off-hand the approximate price of the different > versions? (ModelSim: Designer/PE/SE, Active-HDL: DE/PE/EE) and any Prices is difficult, as e.g. PE is not like PE, you can buy different licenses for PE (VHDL vs Verilog, Floating vs Dongle, ...) and you might get deals when buying more than one SW from same vendor. > key > features that make the more expensive ones worth the cost? For the full range of differences have a look at the Mentor homepage. For me important: - Performance optimisations is SE only, Performance reduction should be designer only. - SE has a lot of features included, that need additional payment for the other simulators - OS support (PE: Win, SE: win, Solaris, Linux (32 and 64 bit), LE: Linux32 only) - Tcl/Tk support is SE bye ThomasArticle: 129024
Hi Nick,
Nick schrieb:
> Thanks for your detailed explanation!
>
> I assign the SDATA to 'Z' in order to receive data, but the pin is
> pulled up so I am wondering if the SDATA will read '1' regardless of the
> actual incoming value.
The simple answer: No, normally the peripheral that puts a '0' on the
SDATA line has a driver that is strong enough to pull the line down.
For further investigation: The voltage on your SDATA line can be modeled
as a resistor network (in case of high speed or high accuracy a RLC
network). This consists mainly of your pullup resistor and the R(DS) of
the CMOS transistors in your connected drivers output stage. With these
values you can use the formulas for a simple voltage divider to
calculate the voltage on your SDATA line.
e.g. Vcc= 3.3V R(pullup) = 1 KOhm R(DSon)= 50 Ohm
V(SDATA) = 3.3V * 50 Ohm/1050 Ohm = 157 mV
which should be read as a '0' on a digital input.
For the actual values in your design take a look in the datasheets of
the devices you use. But the example should give you an idea of what is
going on when pullups meet drivers.
Have a nice synthesis
Eilert
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