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
Jan Panteltje wrote:
> Interesting.
> here is something to think about from the libc.info from gcc C.
> maybe you already support these?
> I recently found out it is better to use these in C then 'int' and 'short',
> as some programs I wrote stopped working when compiled on AMD 64....
> (header file structures with 'int' and 'short' and 'BYTE' ).
The native types, including long long as 64 bit, are in the parser and
emit the expected word length. The current net list generator only
builds signed values which are width+1 in size. Properly implementing
unsigned is part of the next pass work at bring FpgaC inline with
expected normal C implementations.
One of the interesting parts of FpgaC is that
int VeryWideInt:512;
will build a 512 bit plus sign integer ... which doesn't make a very
fast counter, as the carry tree is pretty slow, but you get the
precision asked for.
typedef is also currently missing from FpgaC's parser, and will be
added soon so that standard header files can also be imported into an
FpgaC project.
Article: 91276Hello everyone, This link http://www.easics.be/webtools/crctool has the software to generate the vhdl code for the crc 32 polynomial. But the data bus width is only upto 256 bits. In the below code, crc is computed on only 4 bits of data. But i need to compute the crc on destination address, source address, length, data. which could be 72 nibbles or more. My assumption, is that in each clock cycle i send 4 bits to this combinational logic(logic in the attachment) and the previous new crc becomes C in every clock cycle.So after i am done sending all the data, the final new crc will be the actual crc [32 bits] which is being appended to the end of the frame. Is this assumption right? I will change the variable assignment to the signal assignment though. NewCRC(0) := D(6) xor D(0) xor C(24) xor C(30); NewCRC(1) := D(7) xor D(6) xor D(1) xor D(0) xor C(24) xor C(25) xor C(30) xor C(31); NewCRC(2) := D(7) xor D(6) xor D(2) xor D(1) xor D(0) xor C(24) xor C(25) xor C(26) xor C(30) xor C(31); NewCRC(3) := D(7) xor D(3) xor D(2) xor D(1) xor C(25) xor C(26) xor C(27) xor C(31); NewCRC(4) := D(6) xor D(4) xor D(3) xor D(2) xor D(0) xor C(24) xor C(26) xor C(27) xor C(28) xor C(30); NewCRC(5) := D(7) xor D(6) xor D(5) xor D(4) xor D(3) xor D(1) xor D(0) xor C(24) xor C(25) xor C(27) xor C(28) xor C(29) xor C(30) xor C(31); NewCRC(6) := D(7) xor D(6) xor D(5) xor D(4) xor D(2) xor D(1) xor C(25) xor C(26) xor C(28) xor C(29) xor C(30) xor C(31); NewCRC(7) := D(7) xor D(5) xor D(3) xor D(2) xor D(0) xor C(24) xor C(26) xor C(27) xor C(29) xor C(31); NewCRC(8) := D(4) xor D(3) xor D(1) xor D(0) xor C(0) xor C(24) xor C(25) xor C(27) xor C(28); NewCRC(9) := D(5) xor D(4) xor D(2) xor D(1) xor C(1) xor C(25) xor C(26) xor C(28) xor C(29); NewCRC(10) := D(5) xor D(3) xor D(2) xor D(0) xor C(2) xor C(24) xor C(26) xor C(27) xor C(29); NewCRC(11) := D(4) xor D(3) xor D(1) xor D(0) xor C(3) xor C(4) xor C(25) xor C(27) xor C(28); NewCRC(12) := D(6) xor D(5) xor D(4) xor D(2) xor D(1) xor D(0) xor C(4) xor C(24) xor C(25) xor C(26) xor C(28) xor C(29) xor C(30); NewCRC(13) := D(7) xor D(6) xor D(5) xor D(3) xor D(2) xor D(1) xor C(5) xor C(25) xor C(26) xor C(27) xor C(29) xor C(30) xor C(31); NewCRC(14) := D(7) xor D(6) xor D(4) xor D(3) xor D(2) xor C(6) xor C(26) xor C(27) xor C(28) xor C(30) xor C(31); NewCRC(15) := D(7) xor D(5) xor D(4) xor D(3) xor C(7) xor C(27) xor C(28) xor C(29) xor C(31); NewCRC(16) := D(5) xor D(4) xor D(0) xor C(8) xor C(24) xor C(28) xor C(29); NewCRC(17) := D(6) xor D(5) xor D(1) xor C(9) xor C(25) xor C(29) xor C(30); NewCRC(18) := D(7) xor D(6) xor D(2) xor C(10) xor C(26) xor C(30) xor C(31); NewCRC(19) := D(7) xor D(3) xor C(11) xor C(27) xor C(31); NewCRC(20) := D(4) xor C(12) xor C(28); NewCRC(21) := D(5) xor C(13) xor C(29); NewCRC(22) := D(0) xor C(14) xor C(24); NewCRC(23) := D(6) xor D(1) xor D(0) xor C(15) xor C(24) xor C(25) xor C(30); NewCRC(24) := D(7) xor D(2) xor D(1) xor C(16) xor C(25) xor C(26) xor C(31); NewCRC(25) := D(3) xor D(2) xor C(17) xor C(26) xor C(27); NewCRC(26) := D(6) xor D(4) xor D(3) xor D(0) xor C(18) xor C(24) xor C(27) xor C(28) xor C(30); NewCRC(27) := D(7) xor D(5) xor D(4) xor D(1) xor C(19) xor C(25) xor C(28) xor C(29) xor C(31); NewCRC(28) := D(6) xor D(5) xor D(2) xor C(20) xor C(26) xor C(29) xor C(30); NewCRC(29) := D(7) xor D(6) xor D(3) xor C(21) xor C(27) xor C(30) xor C(31); NewCRC(30) := D(7) xor D(4) xor C(22) xor C(28) xor C(31); NewCRC(31) := D(5) xor C(23) xor C(29);Article: 91277
Kevin Brace <sa0les1@brac2ed3esi4gns5olut6ions.com> writes: > If the number we presented is not satisfactory, we have several > ideas to reducing the LUT count such as: > > * Using multiplexer instead of internal tri-state buffers for > configuration register part of the PCI IP core Will that help? Don't the synthesis tools translate use of tri-state buffers into multiplexers on most of the newer Xilinx FPGAs anyhow, since the parts don't have actual tri-state buffers?Article: 91278
I promised an answer. The digging took a bit longer...
The good news is that Xilinx has many thousands of S3e100 in TQ144, and
hundreds in vq100 packages, as well as many S3500 in several packages.
The bad new is that -today- these parts are still ES ("early silicon")
which distribution hates to touch, because the parts will become
obsolete very soon, once the production version becomes available.
If you need them immediately, order them through your distributor or
your Xilinx sales folks. And realize that "6 to 8 weeks" is often
exaggerated.
Production S3e100 and 500s are expected this month, and 1600 soon
after. And the distis will love to sell them (which they consider their
job, even in Europe !).
I have held the almost final version of the S3e500-based evaluation
board in my hand. It is dynamite, loaded with features and peripherl
circuits, compatible with a slew of inexpensive Digilent add-on boards.
Availability starts in December. Well before that, there will be a
business-card-size eval board, packaged in a DVD-case, meant as a
super-low-cost S3e100 demonstrator.
Spartan3e is really rolling, and will soon be a big success. Too bad
that Marketing created expectations that were impossible to meet.
Keep the faith, Spartan3e is real, and it is coming!
Peter Alfke, Xilinx
Article: 91279Rene Tschaggelar wrote: > Why are those guys so keen on C ? Suggesting compatibility with > something while having least readability ? air_bits@yahoo.com writes: > The description at the project page pretty much says it all: > > "C provides an excellent alternative to VHDL/Verilog for algorithmic > expression of tasks targeting FPGAs for reconfigurable computing." That doesn't explain *why* it's an excellent alternative. I can just as easily state that "C provides a terrible alternative to VHDL/Verilog for algorithmic expression of tasks targetting FPGAs for reconfigurable computing". So why is their statement any more accurate than mine?Article: 91280
air_bits@yahoo.com writes: > One of the interesting parts of FpgaC is that > > int VeryWideInt:512; > > will build a 512 bit plus sign integer ... which doesn't make a very > fast counter, as the carry tree is pretty slow, but you get the > precision asked for. Why is that any better than VeryWideInt: unsigned (511 downto 0); in VHDL? I expect that this can just as easily be expressed in Verilog, too.Article: 91281
On 2 Nov 2005 14:15:16 -0800, "ashwin" <achiluka@gmail.com> wrote: >Hello everyone, > This link http://www.easics.be/webtools/crctool > has the software to generate the vhdl code for the crc 32 polynomial. >But the data bus width is only upto 256 bits. You have found the page that many of us have found useful as a starting point. Typically for regression tests, you may want to set the width to 1 bit, and supply your data to the routine 1 bit at a time. This is the simplest form of CRC hardware, and it is fairly easy to see how it maps to the CRC polynomial. The downside is it computes CRC at only 1 bit per clock cycle. At 10 MBits per second (10BaseT ethernet) this is no big problem, but at 1000 Mbits per second (Gigabit ethernet) this would be pretty much impossible to achieve (only 1 ns per cycle). The solution is to calculate CRC in parallel. The easics crctool lets you choose any width you like from 1 bit to 256 bits. You trade off complexity for speed, with the complexity growing aproximately linearly from 1 bit to 32 bits, then pretty much leveling off from 33 bits to 256 bits. To use the widths other than 1 bit, you need to look at the bit serial form of your data, and take it N bits at a time and feed it to the parallel CRC circuit you have chosen. Due to the byte nature of the data, using an "8 bit at a time" CRC circuit is a fairly natural choice. >In the below code, crc is computed on only 4 bits of data. OK, 4 bits at a time is good too. Has to run at 1/4 of the bit rate or 2 times the byte rate. > But i need to compute the crc on destination address, source address, >length, data. which could be 72 nibbles or more. This works regardless of the packet length. You just take the data and stream it into the CRC circuit at the appropriate rate and width. > My assumption, is that in each clock cycle I send 4 bits to this >combinational logic(logic in the attachment) and the previous new crc >becomes C in every clock cycle. Exactly right. >So after i am done sending all the >data, the final new crc will be the actual crc [32 bits] which is being >appended to the end of the frame. Go back and re-read my previous answer to you. The CRC is complemented then bit reversed to become the FCS that is appended to the end of the frame. >Is this assumption right? I will change the variable assignment to the >signal assignment though. Pretty much. PhilipArticle: 91282
I'm interested on this point, too. If the core is provided as source, the synthesis will probably handle the conversion well. If the core is an .ngo file like the Xilinx alternative, the Xilinx mapper ends up making the supstitution and the synthesis tool (SynplifyPro in my case) is stymied because the black box for the core doesn't have the information to allow the tristates in the core to be converted so the total conversion falls apart. "Eric Smith" <eric@brouhaha.com> wrote in message news:qhsluelmll.fsf@ruckus.brouhaha.com... > Kevin Brace <sa0les1@brac2ed3esi4gns5olut6ions.com> writes: >> If the number we presented is not satisfactory, we have several >> ideas to reducing the LUT count such as: >> >> * Using multiplexer instead of internal tri-state buffers for >> configuration register part of the PCI IP core > > Will that help? Don't the synthesis tools translate use of tri-state > buffers into multiplexers on most of the newer Xilinx FPGAs anyhow, > since the parts don't have actual tri-state buffers?Article: 91283
Eric Smith wrote: > air_bits@yahoo.com writes: > > One of the interesting parts of FpgaC is that > > > > int VeryWideInt:512; > > > > will build a 512 bit plus sign integer ... which doesn't make a very > > fast counter, as the carry tree is pretty slow, but you get the > > precision asked for. > > Why is that any better than > > VeryWideInt: unsigned (511 downto 0); > > in VHDL? I expect that this can just as easily be expressed in Verilog, > too. I can build them at a schematic level too, so why is any HDL better? I can even wire them out of TTL so why is using an FPGA better? Heck, I can even wire them out of diodes or vacumn tubes, .... So why waste people time bitching about others preferences, and the tools they use to implement them. If you like VHDL, certainly use it. have a nice day ;)Article: 91284
air_bits@yahoo.com writes: > I can build them at a schematic level too, so why is any HDL better? > I can even wire them out of TTL so why is using an FPGA better? > Heck, I can even wire them out of diodes or vacumn tubes, .... > > So why waste people time bitching about others preferences, and the > tools > they use to implement them. If you like VHDL, certainly use it. I'm not the one claiming that any particular HDL is better than another. But I'm trying to understand the hype about using C as an HDL. Where is the actual benefit?Article: 91285
Eric Smith wrote: > Rene Tschaggelar wrote: > > Why are those guys so keen on C ? Suggesting compatibility with > > something while having least readability ? > > air_bits@yahoo.com writes: > > The description at the project page pretty much says it all: > > > > "C provides an excellent alternative to VHDL/Verilog for algorithmic > > expression of tasks targeting FPGAs for reconfigurable computing." > > That doesn't explain *why* it's an excellent alternative. I can just > as easily state that "C provides a terrible alternative to VHDL/Verilog > for algorithmic expression of tasks targetting FPGAs for reconfigurable > computing". So why is their statement any more accurate than mine? There are a few hundred thousand engineers on the planet that can express large complex algorithms in C, and a few tens of thousands of engineers that can express large complex algorithms in VHDL/Verilog, and probably a few thousand that can actually grasp the test vector space and simulation effort necessary to actually get a large VHDL/Verilog design working for large complex alogoritsms. So access to design talent is one. There are clear advantages to being able write, test, and debug large complex algorithms on a traditional processor with a source code debugger and moving the nearly finished product to FPGAs for deployment and performance. So access to advanced software development tools is two. The embedded logic analyzer cores are a very poor subsitute when debugging complex algorithms with lots of state and data.Article: 91286
On 2 Nov 2005 14:20:17 -0800, "Peter Alfke" <peter@xilinx.com> wrote:
>I promised an answer. The digging took a bit longer...
>
>The good news is that Xilinx has many thousands of S3e100 in TQ144, and
>hundreds in vq100 packages, as well as many S3500 in several packages.
>The bad new is that -today- these parts are still ES ("early silicon")
>which distribution hates to touch, because the parts will become
>obsolete very soon, once the production version becomes available.
So why not put them in the web store....
Article: 91287
"Peter Alfke" <peter@xilinx.com> wrote in news:1130970017.548080.12630
@z14g2000cwz.googlegroups.com:
> I promised an answer. The digging took a bit longer...
>
> The good news is that Xilinx has many thousands of S3e100 in TQ144,
and
> hundreds in vq100 packages, as well as many S3500 in several packages.
> The bad new is that -today- these parts are still ES ("early silicon")
> which distribution hates to touch, because the parts will become
> obsolete very soon, once the production version becomes available.
>
> If you need them immediately, order them through your distributor or
> your Xilinx sales folks. And realize that "6 to 8 weeks" is often
> exaggerated.
>
> Production S3e100 and 500s are expected this month, and 1600 soon
> after. And the distis will love to sell them (which they consider
their
> job, even in Europe !).
>
> I have held the almost final version of the S3e500-based evaluation
> board in my hand. It is dynamite, loaded with features and peripherl
> circuits, compatible with a slew of inexpensive Digilent add-on
boards.
> Availability starts in December. Well before that, there will be a
> business-card-size eval board, packaged in a DVD-case, meant as a
> super-low-cost S3e100 demonstrator.
>
> Spartan3e is really rolling, and will soon be a big success. Too bad
> that Marketing created expectations that were impossible to meet.
> Keep the faith, Spartan3e is real, and it is coming!
> Peter Alfke, Xilinx
>
Can't wait for December to come! Can I book my order from now?
-Pratip
Article: 91288Eric Smith wrote: > That doesn't explain *why* it's an excellent alternative. I can just > as easily state that "C provides a terrible alternative to VHDL/Verilog > for algorithmic expression of tasks targetting FPGAs for reconfigurable > computing". So why is their statement any more accurate than mine? There are probably a few hundred billion statements of C/C++ IP for designs which contain easily reusable code segments (IE cores) in nearly every application area. Probably a few trillion, when you include privately held IP in addition to what is on SourceForge and other open source depositories. I suspect, the total IP coded in VHDL/Verilog is three to four orders of magnitude less. So that is three reasons why C can be an excellent althernative for reconfigurable computing projects, and for the home hobbyist that already knows C and would like to use an FPGA for a reconfigurable platform for their robotic or other project.Article: 91289
Hello group, First of all I have tried to download the reference design for the ML403 twice today with no luck. The download page is completely empty. Could somebody at Xilinx please fix this? I can open the ml402_emb_ref_mb on my desktop but when I transfered the files to my laptop I get a "Can not find MPD for IP opb_uart16550 1.00.d I have similar issues with the ml403 ref designs. This seems to be a non free $ iconed IP on the System Pane. Is this a security issue? Do I have to get a different registration number for my laptop? Or is this an XP Professional Issue which is on my laptop and not on my desktop? Thanks for your advice in advance. Peace, Brad Smallridge at aivision dot comArticle: 91290
Brad Smallridge wrote: > Hello group, > > First of all I have tried to download the reference design for the ML403 > twice today with no luck. The download page is completely empty. Could > somebody at Xilinx please fix this? Were you at : http://www.xilinx.com/products/boards/ml403/powerpc_microblaze_demos_refsys.htm -Newman > > I can open the ml402_emb_ref_mb on my desktop but when I transfered the > files to my laptop I get a "Can not find MPD for IP opb_uart16550 1.00.d I > have similar issues with the ml403 ref designs. > > This seems to be a non free $ iconed IP on the System Pane. Is this a > security issue? Do I have to get a different registration number for my > laptop? > > Or is this an XP Professional Issue which is on my laptop and not on my > desktop? > > Thanks for your advice in advance. > > Peace, > > Brad Smallridge at > aivision dot comArticle: 91291
Jeremy Stringer schrieb: > It's not a website, but a good book on computer architecture would > probably help in the kind of stuff that you're interested in. Not > FPGA-specific, but easy to apply in an FPGA. Some books which are maybe helpfull: - The Definitive Guide to How Computers Do Math: Featuring the Virtual DIY Calculator - http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0471732788.html - http://www.soccentral.com/results.asp?EntryID=16144 - THE DESIGN WARRIOR'S GUIDE TO FPGAS - http://www.elsevier.com/wps/find/bookdescription.cws_home/699634/description#description Greetings UdoArticle: 91292
air_bits@yahoo.com wrote: > Eric Smith wrote: > >>That doesn't explain *why* it's an excellent alternative. I can just >>as easily state that "C provides a terrible alternative to VHDL/Verilog >>for algorithmic expression of tasks targetting FPGAs for reconfigurable >>computing". So why is their statement any more accurate than mine? > > > There are probably a few hundred billion statements of C/C++ IP for > designs which > contain easily reusable code segments (IE cores) in nearly every > application > area. Probably a few trillion, when you include privately held IP in > addition > to what is on SourceForge and other open source depositories. > > I suspect, the total IP coded in VHDL/Verilog is three to four orders > of magnitude less. > > So that is three reasons why C can be an excellent althernative for > reconfigurable computing projects, and for the home hobbyist that > already knows C and would like to use an FPGA for a reconfigurable > platform for their robotic or other project. How about some examples, of some real applications, that can be coded in either, and the resulting source examples, and the FPGA resource mapping that results ? I presume a mixed-language design is possible ? - an example of that as well, would assist understanding. Otherwise, it's all arm-waving..... -jgArticle: 91293
Eric Smith wrote: > I'm not the one claiming that any particular HDL is better than > another. But I'm trying to understand the hype about using C as > an HDL. Where is the actual benefit? You have it backwards. The intent is not to use C for hardware design, but to use FPGA's for computing. There is a grey area in between, but the view point is from completely different ends of the problem design space.Article: 91294
Jim Granville wrote: > How about some examples, of some real applications, that can be coded > in either, and the resulting source examples, and the FPGA resource > mapping that results ? > > I presume a mixed-language design is possible ? - an example of that > as well, would assist understanding. > > Otherwise, it's all arm-waving..... Most applications of reconfigurable computing are not hardware design applications, so any pure HDL may be the wrong tool, as it's design focus is at the gate/register level. Reconfigurable computing is about taking tranditional C/C++ applications and pushing the resource intensive parts into net lists for a performance gain ... frequenly as much as 200 times the fastest RISC/CISC processors by removing memory latency and ALU pipelines (both of which are serial resources) from the critical path. Moving the front end of web servers, router/classifier logic and TCP/IP stacks into several large FPGA's ... VertexII-Pro's with rocket IO's and PPC backend engines is one example. These applications are already written in C, and get married to the external hardware with logic typically written in VHD/Verilog. Likewise, most protocol converters which interface different fibre connections are freqently being pushed into fpga's to maintain wire speed operation. Mixed C, VHDL, Verilog, and schematic are all very likely. C is just one more implementation tool.Article: 91295
air_bits@yahoo.com writes: > There are a few hundred thousand engineers on the planet that can > express large complex algorithms in C, and a few tens of thousands of > engineers that can express large complex algorithms in VHDL/Verilog, Of those few hundred thousand that know C, very few have any clue how to design hardware. If you turn them loose with C as an HDL, you're going to end up with really crappy hardware, just like when programmers are thrust into Verilog or VHDL. It's not knowledge of the syntax of a particular language that's the problem. The semantics of hardware design are fundamentally different from the semantics of sequential software design. > and probably a few thousand that can actually grasp the test vector > space and simulation effort necessary to actually get a large > VHDL/Verilog design working for large complex alogoritsms. Are you claiming that test vectors and simulation aren't needeed when using C as an HDL? I'd be very skeptical of any such assertion. > The embedded logic analyzer cores are a very poor subsitute when > debugging complex algorithms with lots of state and data. What's that got to do with your choice of HDL? If you want to know what's going on inside your FPGA, that's not fundamentally any easier with C as your HDL than it is with Verilog or VHDL. EricArticle: 91296
air_bits@yahoo.com writes: > You have it backwards. The intent is not to use C for hardware design, > but to use FPGA's for computing. There is a grey area in between, but > the view point is from completely different ends of the problem design > space. You're right, I wasn't aware of that distinction. Still, if you're going to use reconfigurable computing, surely each configuration is a hardware design, and much better expressed in a language optimized for hardware design, rather than a language optimized for strictly sequential operation. EricArticle: 91297
Newman wrote: > Brad Smallridge wrote: > >>Hello group, >> >>First of all I have tried to download the reference design for the ML403 >>twice today with no luck. The download page is completely empty. Could >>somebody at Xilinx please fix this? > > > Were you at : > http://www.xilinx.com/products/boards/ml403/powerpc_microblaze_demos_refsys.htm From this part of the world, the whole Xilinx website is out to lunch ( and has been for a couple of days )? Altera and Atmel ( and everyone else ) web sites are fine, so seems to be a Xilinx specific problem. -jgArticle: 91298
Jim Granville wrote: > Newman wrote: > >> Brad Smallridge wrote: >> >>> Hello group, >>> >>> First of all I have tried to download the reference design for the ML403 >>> twice today with no luck. The download page is completely empty. Could >>> somebody at Xilinx please fix this? >> >> >> >> Were you at : >> http://www.xilinx.com/products/boards/ml403/powerpc_microblaze_demos_refsys.htm >> > > > From this part of the world, the whole Xilinx website is out to lunch > ( and has been for a couple of days )? > > Altera and Atmel ( and everyone else ) web sites are fine, so seems to > be a Xilinx specific problem. > > -jg Just tested again - it has improved slightly. Now, Firefox can open www.xilinx.com OK, but the same URL pasted into Netscape, chokes with "page has no data" .... -jgArticle: 91299
Peter wrote: > I have held the almost final version of the S3e500-based evaluation > board in my hand. Any chance of releasing the user manual before the boards show up? > It is dynamite, loaded with features and peripherl circuits, > compatible with a slew of inexpensive Digilent add-on boards. Does that mean Xilinx stuck with the (hopelessly outdated) 40 pins, one ground (Note 1) I/O connector pinout of the older Digilent boards? Cheap evaluation boards are great resources, but continuing to design and ship evaluation boards for sub-ns edge rate CMOS parts with such a poorly grounded I/O header is just plain silly. Is there a decent high speed I/O connector provided? ( Doesn't even have to be anything fancier than a dual row 0.1" header, just ground one row of the connector, and properly route some diff pairs out ) or, as I suggested when the S3 board came out: > > The pinout probably was picked to match that of the the older >Digilent boards; however, it looks like there's enough room on the >layout to add a third row of ground pins so the end user could snip >off the pre-stuffed two row headers and use a three row header instead. > > An I/O connector with diff. pair routing and provision for VRP/VRN >resistors and VREF bank pins would also be handy. > Brian (Note 1) and for anyone counting VCC pins as returns, the S3 eval kit has one plane VCC pin, no bypass caps nearby, with IO connector traces merrily crossing VCC plane cuts
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