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
Mike Harrison wrote: > I want to use the Xilinx Spartan-6 XAPP495 HDMI/DVI transmit/receive modules, which are written in > Verilog, in a new VHDL project, as I'm much more familiar with VHDL - I don't do enough FPGA stuff > to justify the time to learn a new language for one project. > > Can anyone point me towards how I can include the verilog modules and make the signals visible to > my VHDL - any example of a verilog module included in a VHDL project would probably give me enough > to go on. > The simplest way is using the ISE NAvigator GUI. Add the verilog source file to the project. Then highlight the file in the Hierarchy window (clik once) and in the design process window you should see "View HDL instantiation template." In a VHDL project, the template should default to VHDL, but if for some reason it shows up in Verilog, you can change the properties for "View HDL Instantiation Template" by right clicking and there is a drop-down menu to select the language. The VHDL template will contain the entity declaration as well as an instantiation template. -- GaborArticle: 153176
On Dec 21 2011, 3:07=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > This is all true, but the question is jitter. =A0If you only have one ADC= , > then skew isn't usually a problem. =A0Jitter can be. The OP stated he had 2 ADCs. Skew can be a problem with 2 ADCs, depending upon the application. AndyArticle: 153177
Just installed ISE webpack 13.3 on my laptop and things are getting a bit tight space-wise - a lot of space (several gb) appears to be used by files for device families I'll never use, but removing the dirs makes the software bork. There's presumably a file/dir list somewhere telling it what to look for - has anyone figured out where this is ? Removing the EDK dir is the only thing I've found so far that appears not to break anythingArticle: 153178
Mike Harrison wrote: > Just installed ISE webpack 13.3 on my laptop and things are getting a bit tight space-wise - a lot > of space (several gb) appears to be used by files for device families I'll never use, but removing > the dirs makes the software bork. > > There's presumably a file/dir list somewhere telling it what to look for - has anyone figured out > where this is ? > > Removing the EDK dir is the only thing I've found so far that appears not to break anything If you spend more than an hour for slimming down the installation, it is cheaper to buy an external hard disk. -- Frank Buss, http://www.frank-buss.de piano and more: http://www.youtube.com/user/frankbussArticle: 153179
On Wed, 04 Jan 2012 13:06:42 -0000, Frank Buss <fb@frank-buss.de> wrote: > If you spend more than an hour for slimming down the installation, it is > cheaper to buy an external hard disk. Agreed. I have both ISE and Quartus installed on a 16G pen drive. Under Linux I just bind it to /opt and everything's happy. Surprisingly it doesn't seem to hurt performance noticeably either.Article: 153180
Mike Harrison <mike@whitewing.co.uk> wrote: > Just installed ISE webpack 13.3 on my laptop and things are getting a > bit tight space-wise - a lot of space (several gb) appears to be > used by files for device families I'll never use, but removing the > dirs makes the software bork. On the all-too-small SSD in my laptop, I have enabled the built-in transparent folder compression in Windows for the Xilinx folder. This reduces the size of the ISE 10.1 (old, I know) installation from 9.4GB to 5.6GB. I expect something similar could be done on Linux. I didn't measure the impact on performance, but since synthesis and P&R are mainly CPU intensive, not disk I/O intensive, I've assumed it is not significant. Regards, LaustArticle: 153181
Hello,
I am trying to decide what board to order for a project I want to do betwee=
n April and June in school, and for other projects, mainly to exercise VHDL=
and design interesting projects. The school project itself is the design o=
f a general purpose DSP data path.
I have currently staked out the following boards, based upon the features I=
need and the price.
Digilent | Atlys |
Enterpoint | Drigmorn-3 |
Xilinx | 3A Starter kit |
Enterpoint | Drigmorn-2 |
Xilinx | 3E Starter kit |
However, also delivery time and ease of ordering are somewhat necessary, an=
d three of the five boards come from the US, while 2 come from the UK, and =
I live in Belgium.
On the other hand, the Drigmorn boards do not feature a video output (whate=
ver type), which is also something I would like to have.
And then there is the choice of FPGA:
LX16 XC3S700A
Logic cells: 14579 13248
Slices : 2278 5888
Block RAM : 576 360
Distributed RAM: 136 92
Since a LX16 seems to have less slices than a XC3S700A, does that mean that=
the LX16 will reach its maximum earlier than the XC3S700A? Conversely, doe=
s the lesser amount of distributed RAM on the XC3S700A mean that it could b=
e that in a pipelined design it has less possibilities than the LX16?
I must say, that if I have to select purely on price, this would certainly =
favor the Drigmorn-2, but does the choice of the XC3S700A FPGA in that case=
limit me in my design choices?
And another point, I only own a MacBook Air anymore, with Linux on Virtualb=
ox and ISE inside it, but how does this translate in my choices for program=
ming the selected board?
Regards,
Jurgen Defurne
Article: 153182I am very new to FPGA programming. I'm using "FPGA Prototyping by VHDL examples" to learn VHDL. I've gotten up to section 4.5.3 FIFO buffer, and am having trouble understanding what might happen in the code... In the 'register file' section, array_reg(w_ptr_reg) is set to w_data. In the fifo control section, w_ptr_reg is set to w_ptr_next. Both events happen when clk'event and clk='1'. Is there any guarantee as to which one happens first? How do I know whether array_reg(???) will use w_ptr_reg as the index, or w_ptr_next? If there is anyone who is working through this same book, I'd like to start an email correspondence. BillArticle: 153183
In article <8lf9g7dq02hfn7lmf5cnmjm4atidskuqte@4ax.com>, Bill <bfmackin@nospam.mchsi.com> wrote: >I am very new to FPGA programming. I'm using "FPGA Prototyping by >VHDL examples" to learn VHDL. I've gotten up to section 4.5.3 FIFO >buffer, and am having trouble understanding what might happen in the >code... > >In the 'register file' section, array_reg(w_ptr_reg) is set to w_data. > >In the fifo control section, w_ptr_reg is set to w_ptr_next. > >Both events happen when clk'event and clk='1'. > > >Is there any guarantee as to which one happens first? How do I know >whether array_reg(???) will use w_ptr_reg as the index, or w_ptr_next? > Well, I don't have the book, so I'm giving this advice blind - but - you're not thinking hardware. What hardware does the VHDL represent? There's no "first" in the above - they're happening at the same time - at the postive edge of a clk. Draw out what you think the hardware will look like. Sketch a few timing diagrams. Under what timing conditions will things work as intended? >If there is anyone who is working through this same book, I'd like to >start an email correspondence. Just use this thread, so others can contribute too. Regards, MarkArticle: 153184
Mark Curry <gtwrek@sonic.net> wrote: > In article <8lf9g7dq02hfn7lmf5cnmjm4atidskuqte@4ax.com>, > Bill <bfmackin@nospam.mchsi.com> wrote: >>I am very new to FPGA programming. I'm using "FPGA Prototyping by >>VHDL examples" to learn VHDL. I've gotten up to section 4.5.3 FIFO >>buffer, and am having trouble understanding what might happen in the >>code... (snip) >>Both events happen when clk'event and clk='1'. >>Is there any guarantee as to which one happens first? How do I know >>whether array_reg(???) will use w_ptr_reg as the index, or w_ptr_next? > Well, I don't have the book, so I'm giving this advice blind - but - > you're not thinking hardware. What hardware does the VHDL represent? > There's no "first" in the above - they're happening at the same time - at > the postive edge of a clk. Also, note that the FIFO is usually built from a dual-port RAM, so that it can write a new entry and read an old one at the same time. Since you didn't mention it, I presume your FIFO doesn't have separate read and write clocks, though that is also allowed. -- glenArticle: 153185
Don't confuse execution order with simulation time. Seqential statements execute in sequential order, one after the other, without consuming any simulation time (except a wait statement). Simulation time only advances while the process is suspended (e.g. waiting for the next clock edge, whether explicitly executing a wait statement, or implicitly at the bottom of a process that has a sensitvity list). If w_ptr_reg is a signal, its value is not actually updated until (in execution order) the process suspends (to wait for another clock). So, references to a signal, whether they occur before or after (in execution order, not simulation time) the assignment to it, return the non-updated value. This is different from how software code works in typical programming languages. If w_ptr_reg is a variable, it works just like software; the variable is updated immediately upon execution of the assignment statement (or procedure call, if it is an out or inout parameter). So references to a variable occurring before (in execution order) the assignment will return the non-updated value, but references to the variable occuring after (in execution order) the assignment will return the updated value. Whether you use variables or signals, the synthesis tool will create hardware (i.e. gates and registers) that mimics the simulation behavior of the code. Whether that hardware is fits in the device or meets timing constraints is a different issue. I find it works best for me if I focus on coding the correct behavior, then worry about what hardware it generates if it does not fit or meet timing. Of course, with experience comes the knowledge of what types of behavior take too much resources or won't meet timing! Because of my preference and experience, I use more variables, saving signals for only inter- process communications. AndyArticle: 153186
Andy <jonesandy@comcast.net> wrote: > Don't confuse execution order with simulation time. Seqential > statements execute in sequential order, one after the other, without > consuming any simulation time (except a wait statement). Simulation > time only advances while the process is suspended (e.g. waiting for > the next clock edge, whether explicitly executing a wait statement, or > implicitly at the bottom of a process that has a sensitvity list). This is all true, but with a FIFO things get much more interesting. Consider that the write data could come just before, at the same time as (more likely in simulation than actual practice) or just after the read cycle. The FIFO has to handle all three cases. (If the FIFO is empty, you shouldn't even try reading, and if full you shouldn't write.) Some immediately pass data written to an empty FIFO to the output, others don't. > If w_ptr_reg is a signal, its value is not actually updated until (in > execution order) the process suspends (to wait for another clock). So, > references to a signal, whether they occur before or after (in > execution order, not simulation time) the assignment to it, return the > non-updated value. This is different from how software code works in > typical programming languages. I usually write mostly structural verilog (module references and continuous assignment) but sometimes behavioral. When I do write behavioral verilog, I try to order the statements such that the result is the same as if they were executed sequentially. (snip) > Whether you use variables or signals, the synthesis tool will create > hardware (i.e. gates and registers) that mimics the simulation > behavior of the code. Whether that hardware is fits in the device or > meets timing constraints is a different issue. I find it works best > for me if I focus on coding the correct behavior, then worry about > what hardware it generates if it does not fit or meet timing. Of > course, with experience comes the knowledge of what types of behavior > take too much resources or won't meet timing! Because of my preference > and experience, I use more variables, saving signals for only inter- > process communications. Well, real hardware timing may result in hardware that works and a simulation that doesn't, if you aren't careful with the way you write the statements. -- glenArticle: 153187
On Jan 4, 6:44=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Andy <jonesa...@comcast.net> wrote: > > Don't confuse execution order with simulation time. Seqential > > statements execute in sequential order, one after the other, without > > consuming any simulation time (except a wait statement). Simulation > > time only advances while the process is suspended (e.g. waiting for > > the next clock edge, whether explicitly executing a wait statement, or > > implicitly at the bottom of a process that has a sensitvity list). > > This is all true, but with a FIFO things get much more interesting. > > Consider that the write data could come just before, at the same time > as (more likely in simulation than actual practice) or just after > the read cycle. The FIFO has to handle all three cases. > (If the FIFO is empty, you shouldn't even try reading, and if full > you shouldn't write.) > > Some immediately pass data written to an empty FIFO to the output, > others don't. > > > If w_ptr_reg is a signal, its value is not actually updated until (in > > execution order) the process suspends (to wait for another clock). So, > > references to a signal, whether they occur before or after (in > > execution order, not simulation time) the assignment to it, return the > > non-updated value. This is different from how software code works in > > typical programming languages. > > I usually write mostly structural verilog (module references and > continuous assignment) but sometimes behavioral. =A0When I do write > behavioral verilog, I try to order the statements such that the > result is the same as if they were executed sequentially. > > (snip) > > > Whether you use variables or signals, the synthesis tool will create > > hardware (i.e. gates and registers) that mimics the simulation > > behavior of the code. Whether that hardware is fits in the device or > > meets timing constraints is a different issue. I find it works best > > for me if I focus on coding the correct behavior, then worry about > > what hardware it generates if it does not fit or meet timing. Of > > course, with experience comes the knowledge of what types of behavior > > take too much resources or won't meet timing! Because of my preference > > and experience, I use more variables, saving signals for only inter- > > process communications. > > Well, real hardware timing may result in hardware that works and a > simulation that doesn't, if you aren't careful with the way you > write the statements. > > -- glen I missed an important detail. The OP does not mention whether both assignment and reference are in the same process (I assumed they were). If the signal assignment is in one process, another process (clocked on the same edge of same clock signal) referencing the same signal will not see the updated value until the next clock edge. All VHDL processes scheduled to run in the same delta cycle must suspend before any of their driven signals are updated. If two or more processes are both sensitive to the same clock signal, then they will run in the same delta cycle. The issues of (non-shared) variables' update semantics affecting inter-process communication is completely avoided in VHDL, by not allowing (non-shared) variables to be accessed by multiple processes in the first place. Verilog's semantic parallel to VHDL's signal/variable is the non-blocking/blocking assignment. Unfortunately, verilog simulators are perfectly happy running code that performs blocking assignments and accesses in different "processes" (always blocks), even though the behavior is undefined/ erratic. This makes using these features riskier in Verilog (unless you have a good linting tool, which is a must with Verilog, IMHO). Things to look for if simulation behavior differs from the hardware: Synthesis reported warnings/errors, Static timing analysis (STA) reported warnings/errors, Delta delay issues on clock signals (usually caused by assigning one clock signal from another, then moving data between processes clocked by both), Incorrectly defined multi-cycle or false path constraints (and not running full-timing simulations to verify them) Testbench issues (incorrectly representing actual HW interface counterparts), Synthesis or simulator bug, ... there are probably others. In VHDL, with regard to variables, signals and orders of assignments and references, the behavior of synchronous processes (and therefore of the synthesized HW) is very well defined by the LRM, making differences in their behavior (excepting the above) extremely rare in my experience. AndyArticle: 153188
>I am very new to FPGA programming. I'm using "FPGA Prototyping by >VHDL examples" to learn VHDL. I've gotten up to section 4.5.3 FIFO >buffer, and am having trouble understanding what might happen in the >code... [elided] In real-world usage for Xilinx FPGAs, you do not write code that will be synthesized into a FIFo. You use their CoreGen tool to generate a FIFO block, and instantiate that into the controlling logic. However, what others have already said about the essentially simultaneous nature of hardware versus the sequential programming paradigm holds true. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153189
On Thu, 05 Jan 2012 10:40:08 -0600, RCIngham wrote: >>I am very new to FPGA programming. I'm using "FPGA Prototyping by VHDL >>examples" to learn VHDL. I've gotten up to section 4.5.3 FIFO buffer, >>and am having trouble understanding what might happen in the code... > > [elided] > > In real-world usage for Xilinx FPGAs, you do not write code that will be > synthesized into a FIFo. You use their CoreGen tool to generate a FIFO > block, and instantiate that into the controlling logic. Actually, in what passes for the real world here, I find a description that makes the Xilinx tools make an effective use of FPGA resources. This has more to do with my personal strong anti-"wizard" bias, and a desire to write portable HDL. I suspect that if writing HDL took up a bigger proportion of my professional life than the 2% or so that it does, that my attitude might differ. > However, what others have already said about the essentially > simultaneous nature of hardware versus the sequential programming > paradigm holds true. Yes. When you write software you should be thinking in the back of your mind what the processor will be doing (and possibly what the compiler's optimizer will do, first). When you write Verilog or VHDL you should be thinking in the back of your mind what logic will be generated. I have to admit that when I do this most of the blocks have "74HCxx" on them, but you still want to devote part of your brain to thinking what actual hardware will get used: it keeps you from doing really stupid things. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.comArticle: 153190
chthon wrote: > I am trying to decide what board to order for a project I want to do between April and June in school, and for other projects, mainly to exercise VHDL and design interesting projects. The school project itself is the design of a general purpose DSP data path. > > I have currently staked out the following boards, based upon the features I need and the price. > > Digilent | Atlys | > Enterpoint | Drigmorn-3 | > Xilinx | 3A Starter kit | > Enterpoint | Drigmorn-2 | > Xilinx | 3E Starter kit | I have the 3E starter kit and it is nice, but depends on what you need. It is from Xilinx, so it works with your ISE installation (if USB works from within your VM installation, but should be no problem). The advantage is that it has many peripheral components intergrated on the board and a VGA connector. But if you need e.g. just 16 colors, you could easily build your own VGA output with a R2R network (that's what they are using on the starter kit anyway), or attach a LCD display, and then you could buy a cheaper kit, like this nice one: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=593 This uses a Cyclone FPGA from Altera. I have this, too, and it is awesome. I think for beginners the Quartus IDE is easier than the Xilinx IDE, especially the MegaWizard is nice. -- Frank Buss, http://www.frank-buss.de piano and more: http://www.youtube.com/user/frankbussArticle: 153191
> Since a LX16 seems to have less slices than a XC3S700A, does that > mean that the LX16 will reach its maximum earlier than the XC3S700A? > Conversely, does the lesser amount of distributed RAM on the XC3S700A > mean that it could be that in a pipelined design it has less > possibilities than the LX16? The Spartan-6 has a different architecture to the Spartan-3*, so it's a little tricky to compare them directly using some of these numbers. If you have an existing design, you can try implementing it on the two and see how well it maps to either architecture. In general, the Spartan-6 is newer and better, and adds some hardware (PLL, SERDES), which may or may not be useful to you. > On the other hand, the Drigmorn boards do not feature a video output > (whatever type), which is also something I would like to have. As Frank said, a VGA output port can be quite easy to add on. If you're interested in HDMI/DVI, it will be a lot easier to buy a board that includes this facility. Personally, I've found that while not the cheapest board by a long shot, the Digilent ATLYS currently offers the best value for money (at least in the Xilinx space) if you qualify for the academic discount as it includes quite a large chip (XC6SLX45), DDR2, gigabit Ethernet, four HDMI ports (two input, two output), and high speed I/O. I've written some notes on the board here: http://tristesse.org/DigilentAtlysResources I've also compiled a list of cheap development boards: http://tristesse.org/CheapFPGADevelopmentBoards > And another point, I only own a MacBook Air anymore, with Linux on Virtualbox and ISE inside it, but how does this translate in my choices for programming the selected board? I use ISE through Windows on Parallels Desktop and there are no problems whatsoever. Make sure you use one the supported Linux distributions (and a supported version of that distribution - this will not necessarily be the latest!) and you shouldn't have too much trouble with ISE. Some non-Xilinx boards use their own JTAG adapter and proprietary software, so make sure a Linux/Mac version is available. Alternatively, you can get a Xilinx Platform Cable USB II (or something that pretends to be one) and you should have no trouble using Xilinx iMPACT directly. JoelArticle: 153192
Hi guys. I'm currently working on the HDL code for an open-source project which images 'strange and unusual' magnetic media (mainly floppy discs but also MFM and RLL hard disc drives). To do this, I measure the time between incoming pulses on the RD_DATA line. One pulse indicates a magnetic transition. The time between a given pair of pulses encodes (in a roundabout way) a data bit. This is a gross oversimplification, but serves the purpose for this explanation. After measuring the time between two pulses, it re-arms and measures between the second pulse and the one following it. Rinse, repeat. The captured timing values are stored in an on-FPGA FIFO buffer, then passed onto an off-chip Cypress 100MHz 512K*8bit high speed static RAM (this thing needs A LOT of storage). The period counter's reference clock is 100MHz. 10 nanoseconds per count. The most significant bit is reserved for a 'flag' bit (it's used by other parts of the design), leaving a range of 0 to 127 for the counter. The problem is, a lot of the timing values are about 800 counts long. To work around this, I implemented logic to store a 'special' value in the stream if the counter overflows from 127 to 0. This value is "8'd0" -- 8 bits, all zeroes. This raises a problem: if any two incoming pulses are measured at exactly 128 clocks apart (or a modulo thereof), the HDL stores a carry (0x00)... immediately followed by the value of the counter, which is 0x00 (because the count of clock pulses is a multiple of 128). This is messing up the datastream, and I only caught it because a friend mentioned it, I added a test case to the testbench, and I got a truckload of assertion failures. The Verilog code is here: http://hg.discferret.com/microcode/file/1b4ea3919380/DiscReader.v http://hg.discferret.com/microcode/file/1b4ea3919380/ Flag_Delay1tcy_OneCycle.v (other modules are here if you need them: http://hg.discferret.com/ microcode/file/1b4ea3919380 ) I have also rewritten DiscReader.v to use a free-running counter (which seems like a better solution) -- that version is here: http://pastebin.com/evMtjXWj Feel free to offer comments on either of these... the rewrite is later code, and as far as I can tell fully synchronous to the clock (the older code has some other corner cases -- hence the rewrite). Effectively the byte-stream format is: CARRY starts at 0. 0x00 or 0x80 -- add 128 to CARRY. Anything else -- the timing value is CARRY + (this_byte AND 0x7F). Clear CARRY to zero afterwards. The best idea I've come up with thus far is to scrap the overflow logic, cause the acquisition to abort with an error state if the timer overflows, and use a 12-bit or larger counter (which would allow for a maximum count of 40us). This would of course mean I'd have to rewrite the RAM controller logic to handle a 16-bit stream and chunk it into bytes... :( Can anyone think of a good way to resolve this, ideally without introducing timing jitter (although the acquisition clock is PLL'd off a 20MHz TTL oscillator, so there's probably a bit of that already)? I'm not overly attached to the bitstream format, so feel free to propose changes. Thanks, -- Phil. philpem@philpem.me.uk http://www.philpem.me.uk/Article: 153193
Philip Pemberton <philpem@philpem.me.uk> wrote: > I'm currently working on the HDL code for an open-source project which > images 'strange and unusual' magnetic media (mainly floppy discs but also > MFM and RLL hard disc drives). > To do this, I measure the time between incoming pulses on the RD_DATA > line. One pulse indicates a magnetic transition. The time between a given > pair of pulses encodes (in a roundabout way) a data bit. This is a gross > oversimplification, but serves the purpose for this explanation. > After measuring the time between two pulses, it re-arms and measures > between the second pulse and the one following it. Rinse, repeat. > The captured timing values are stored in an on-FPGA FIFO buffer, then > passed onto an off-chip Cypress 100MHz 512K*8bit high speed static RAM > (this thing needs A LOT of storage). The period counter's reference clock > is 100MHz. 10 nanoseconds per count. The most significant bit is reserved > for a 'flag' bit (it's used by other parts of the design), leaving a > range of 0 to 127 for the counter. The bit rate for floppies is 125000b/s at the low end, and, as far as I know, 1000000b/s at the high end. To decode FM or MFM data, you don't need a hugh amount of resolution. There are only two different times between transitions, at least ideally. The GCR code used by older Apple formats has more different times, but not all that many, and the bit rate is on the low side. To write a floppy from data, you need to consider precompensation, which needs a little finer timing. Note that writing a floppy from your data stream, you will also need to consider precompensation. Anyway, my suggestion is to use a slower clock. Then it should only overflow at splice points, or other places where the data doesn't matter. > The problem is, a lot of the timing values are about 800 counts long. To > work around this, I implemented logic to store a 'special' value in the > stream if the counter overflows from 127 to 0. This value is "8'd0" -- 8 > bits, all zeroes. The design of codes that can be uniquely decoded is well known. One answer is to store one more than the overflow value. That is, a 128 count should be X'0001', so X'00' always means overflow, and never data. X'007f' then will be 254, and X'000001' will be 255. The logic is a little more complicated, but shouldn't be hard to fit into an FPGA. -- glenArticle: 153194
Guys I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power plane. It is showing a 30mV voltage drop across the BGA itself, let alone getting the power to the BGA which is dropping another 50mV. Surely the 30mV cannot be true as there is a power plane in the BGA package itself. Historically I would look at the size of the plane and assume that everything is fine and I can't help wondering whether this worst case analysis is a bit pointless. Any opinions? BTW I'm already just beyond the PCB thickness I'm allowed so I can't just use thicker copper. Colin PS. sorry about using Google, I'm sitting in the UK behind a firewall controlled by an Indian call centre.Article: 153195
On Fri, 06 Jan 2012 02:49:54 +0000, Philip Pemberton wrote: > Hi guys. > > I'm currently working on the HDL code for an open-source project which > images 'strange and unusual' magnetic media (mainly floppy discs but > also MFM and RLL hard disc drives). > > To do this, I measure the time between incoming pulses on the RD_DATA > line. One pulse indicates a magnetic transition. The time between a > given pair of pulses encodes (in a roundabout way) a data bit. ... > The problem is, a lot of the timing values are about 800 counts long. To > work around this, I implemented logic to store a 'special' value in the > stream if the counter overflows from 127 to 0. This value is "8'd0" -- 8 > bits, all zeroes. Consider A-law (or mu-law) encoding instead. - BrianArticle: 153196
On Jan 6, 10:55=A0am, "colin_toog...@yahoo.com" <colin_toog...@yahoo.com> wrote: > Guys > > I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power > plane. It is showing a 30mV voltage drop across the BGA itself, let > alone getting the power to the BGA which is dropping another 50mV. > > Surely the 30mV cannot be true as there is a power plane in the BGA > package itself. Power planes have a finite resistance per square, and logic frequently slurps up a lot of current. One of the joys of mixed signal design is trying to stop digital supply current from returning through the ground connections used to define an analog ground. <snip> -- Bill Sloman, NijmegenArticle: 153197
Brian Drummond <brian@shapes.demon.co.uk> wrote: > On Fri, 06 Jan 2012 02:49:54 +0000, Philip Pemberton wrote: >> I'm currently working on the HDL code for an open-source project which >> images 'strange and unusual' magnetic media (mainly floppy discs but >> also MFM and RLL hard disc drives). >> To do this, I measure the time between incoming pulses on the RD_DATA >> line. One pulse indicates a magnetic transition. The time between a >> given pair of pulses encodes (in a roundabout way) a data bit. >> The problem is, a lot of the timing values are about 800 counts long. To >> work around this, I implemented logic to store a 'special' value in the >> stream if the counter overflows from 127 to 0. This value is "8'd0" -- 8 >> bits, all zeroes. > Consider A-law (or mu-law) encoding instead. That should work. I think, though, that it doesn't matter much. The gaps between sectors, and between the before/after the index address mark, all have data bits in them as formatted. The problem comes with write splice. (Put "write splice" floppy into google, and some hits will be for floppy controllers. At least the one for the 279x describes the track format.) Each sector has a header with the track/sector/side/length bytes. When writing, the controller finds the header for the appropriate sector, counts off a specific number of bytes (different for FM and MFM), then turns on the write current. It then writes some binary zeros, an address mark, followed by the data, CRC, a few more bytes, then turns the write current off. The point where it turns on and off is the write splice, and I believe that is where you see the long counts. The exact length doesn't matter much, and will vary between drives, and with the motor speed, with a tolerance of maybe about 10%. The gap after the sector and before the next sector header is long enough such that within tolerance the write splice won't overwrite the next header. The gaps are generously large (but with data bits in them) to allow for a variation in motor speeds and controller clocks. (Much more motor speed than clock.) There are enough data bits after the write splice and before the address mark to sync up the PLL. What is the variation in length for these long counts, and about how many do you find on a track? I presume you start reading on the index pulse, and stop at the next index pulse. If you want to convert a track image back to a floppy, you will start writing at the index pulse, and either stop at the next (if you don't run out of data), or continue writing binary zeros (in FM or MFM form) until the index pulse. -- glenArticle: 153198
On Fri, 06 Jan 2012 01:55:03 -0800, colin_toogood@yahoo.com wrote: > Guys > > I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power > plane. It is showing a 30mV voltage drop across the BGA itself, let > alone getting the power to the BGA which is dropping another 50mV. > > Surely the 30mV cannot be true as there is a power plane in the BGA > package itself. > > Historically I would look at the size of the plane and assume that > everything is fine and I can't help wondering whether this worst case > analysis is a bit pointless. > > Any opinions? > > BTW I'm already just beyond the PCB thickness I'm allowed so I can't > just use thicker copper. I've had this issue in recent designs too. Currents are higher, voltages are lower (1.0, 0.9V, etc), supply tolerances are tighter (3% instead of 5% now for some parts) but copper doesn't seem conduct any better :( About the only thing that's improving is the DC/DC converter; some parts have a reference precision better than 1% now. Transient response is also better due to faster switching frequencies and cheap, large, low ESR caps. The Cu in the BGA is thin. I don't know its sheet resistance, but it's probably greater than the (roughly) 1mohm / square of the inner layers of your PCB. At 20 or 30 amperes, you don't need many squares to get a voltage drop that puts you outside the supply voltage tolerance of the FPGA. In my last "high power" FPGA design, we ended up with a plane on an inner (1/2 oz) layer in parallel with a fill on an outer (1oz) layer for the core supply. The layout guy hated doing it, but it gave adequate results. It might also be possible to use smaller vias in your BGA fanout to reduce the "swiss cheese" effect on your planes, but I haven't tried that in an actual design. I've noticed that some PC motherboard manufacturers are advertising 2oz copper as a feature, so it's not just FPGA folk that are feeling the pain. Regards, AllanArticle: 153199
On Fri, 06 Jan 2012 13:53:05 +0000, Allan Herriman wrote: > On Fri, 06 Jan 2012 01:55:03 -0800, colin_toogood@yahoo.com wrote: > >> Guys >> >> I'm doing hyperlynx power integrity analysis on a Stratix 4 0v9 power >> plane. It is showing a 30mV voltage drop across the BGA itself, let >> alone getting the power to the BGA which is dropping another 50mV. >> >> Surely the 30mV cannot be true as there is a power plane in the BGA >> package itself. >> >> Historically I would look at the size of the plane and assume that >> everything is fine and I can't help wondering whether this worst case >> analysis is a bit pointless. >> >> Any opinions? >> >> BTW I'm already just beyond the PCB thickness I'm allowed so I can't >> just use thicker copper. > > > I've had this issue in recent designs too. Currents are higher, > voltages are lower (1.0, 0.9V, etc), supply tolerances are tighter (3% > instead of 5% now for some parts) but copper doesn't seem conduct any > better :( > > About the only thing that's improving is the DC/DC converter; some parts > have a reference precision better than 1% now. Transient response is > also better due to faster switching frequencies and cheap, large, low > ESR caps. > > > The Cu in the BGA is thin. I don't know its sheet resistance, but it's > probably greater than the (roughly) 1mohm / square of the inner layers > of your PCB. At 20 or 30 amperes, you don't need many squares to get a > voltage drop that puts you outside the supply voltage tolerance of the > FPGA. > > In my last "high power" FPGA design, we ended up with a plane on an > inner (1/2 oz) layer in parallel with a fill on an outer (1oz) layer for > the core supply. The layout guy hated doing it, but it gave adequate > results. > > It might also be possible to use smaller vias in your BGA fanout to > reduce the "swiss cheese" effect on your planes, but I haven't tried > that in an actual design. > > I've noticed that some PC motherboard manufacturers are advertising 2oz > copper as a feature, so it's not just FPGA folk that are feeling the > pain. Another thing I've been doing is to boost the nominal voltage slightly. (Contrived) example: Requirement is 0.9V +/- 3% (i.e. +/- 27mV) at the die. I budget +/- 1% (+/- 9mV) for the transient response. I budget +/- 1% (+/- 9mV) for the initial tolerance. This leaves +/- 1% (+/- 9mV) for the voltage drop. However, the voltage drop is only in the -ve direction. If I change the feedback resistors to move the nominal voltage up by +1% (+ 9mV), I can allow for a voltage drop of 0 to -2% (0 to -18mV). Of course, one can use remote sense on the DC/DC converter to get feedback to eliminate the voltage drop. My experience has been that the degradation of the transient response (due to having a more phase shift in the feedback) isn't worth it. YMMV. Regards, Allan
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