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
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:cl3k1f$kdm$1@gnus01.u.washington.edu... > Inductance should also go down with the thickness of the copper, > though at some point you run into the skin effect. > Thicker copper might be cheaper than more layers. > > -- glen Glen, Good point, but sometimes thicker copper can be a mixed blessing, the etching process can screw up if the copper's too thick. Thinner copper allows narrower tracks. This can let you squeeze your routing together, to get wide tracks to where you need it. Important if you're routing power on a routing layer. On the other hand, thick copper helps heat transfer. Another classic engineering compromise! Best, Syms.Article: 74801
"Jan Bruns": > I plan to design using mostly self-made tools, and upto now, my plan > was to feed completly mapped (but only relativly placed and only partially > routed) CLB-lists through HDL into the xst-flow. > Any suggestions on alternative ways to do this? Ok, I've just found the "xdl" tool, wich will do. Nice. Gruss Jan BrunsArticle: 74802
Austin wrote:
>
> SSO guidelines are on page 23 of:
>
> http://direct.xilinx.com/bvdocs/publications/ds099-3.pdf
>
Except for the leaded S3 packages {VQ/TQ/PQ}, which are still
conspicuously absent from table 23.
Other table 23 oddities:
1) Why are the SSO pin limits for those spiffy current mode
differential drivers so low, nearly the same as for the high
drive single ended I/O standards?
Answer Record 19972 still says "Because the Spartan-3 LVDS
driver is very balanced, its switching causes a negligible
amount of transient current. As a result, SSOs are not a problem."
2) Why are the table 23 SSO limits for the older voltage-mode
differential output drivers {LVPECL,BLVDS} identical to those
of the newer current-mode drivers {LVDS,LDT,RSDS} ?
3) Why do the input-only differential parallel DCI standards
show up in the SSO table?
Brian
Article: 74803I wrote: >>Inductance should also go down with the thickness of the copper, >>though at some point you run into the skin effect. >>Thicker copper might be cheaper than more layers. Symon wrote: > Good point, but sometimes thicker copper can be a mixed blessing, the > etching process can screw up if the copper's too thick. Thinner copper > allows narrower tracks. This can let you squeeze your routing together, to > get wide tracks to where you need it. Important if you're routing power on a > routing layer. On the other hand, thick copper helps heat transfer. > Another classic engineering compromise! I was suggesting it for the power and ground planes, but I don't know which combinations of mixing different thicknesses are allowed. Is a four layer board built from two 2-layer boards etched separately and then put together with an insulation layer in between? It might be that both sides of the separate boards would have to be the same. -- glenArticle: 74804
On Tue, 19 Oct 2004 12:06:21 -0700, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > >I wrote: > >>>Inductance should also go down with the thickness of the copper, >>>though at some point you run into the skin effect. >>>Thicker copper might be cheaper than more layers. > >Symon wrote: > >> Good point, but sometimes thicker copper can be a mixed blessing, the >> etching process can screw up if the copper's too thick. Thinner copper >> allows narrower tracks. This can let you squeeze your routing together, to >> get wide tracks to where you need it. Important if you're routing power on a >> routing layer. On the other hand, thick copper helps heat transfer. >> Another classic engineering compromise! > >I was suggesting it for the power and ground planes, but I don't >know which combinations of mixing different thicknesses are allowed. > >Is a four layer board built from two 2-layer boards etched separately They are called "cores". >and then put together with an insulation layer in between? That is called "prepreg". > It might >be that both sides of the separate boards would have to be the same. That is usually the case, although it is possible to build up copper thickness by plating e.g. the outer layers. Regards, AllanArticle: 74805
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:417470A7.AF16C540@yahoo.com... > Antti Lukats wrote: > > > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > > news:4172C4C1.7EB97771@yahoo.com... > > [snip] > > > > > > NIOS-1 GPL2 licensing > > > > http://www.eecg.toronto.edu/~plavec/utnios.html [snip] > > > > > > > > NIOS-II verilog also exists, but it will not be GPL ;) > > The NIOS-II, thats different, its completly clean-room design, uses no > > vendor primitives at all. some statistic are in my latest post about the > > NIOX core ;) no FPGA tests yet with NIOX (NI*S II compatible) cpu yet. with > > no optimization the NIOX looks like 60MHz+ in slow Virtex devices. > > Is the NIOX core non-public from UT? Or is this another core? NIOX is done by me (3 evnings workload) - its completly clean version written from scratch. It has no pipeline but if running from brams can run about 1 clock instruction except load instructions what is way faster than NIOSII/e I am testing NIOS-II/uCLinux platform simulator at the moment if that is done then I know how to verify NIOX as well, next step would be NIOX/uCLinux SoC AnttiArticle: 74806
Eric, Would you mind to tell me where from? Regards, -- Jaime Andrés Aranguren Cardona jaac@nospam.sanjaac.com SanJaaC Electronics Soluciones en DSP www.sanjaac.com (Remove "nospam" from e-mail address) "Eric Smith" <eric-no-spam-for-me@brouhaha.com> escribió en el mensaje news:qhis97snpo.fsf@ruckus.brouhaha.com... > "Jaime Andrés Aranguren Cardona" <jaac@nospam.sanjaac.com> writes: > > I guess it would fit into an Spartan-3 XC3S200, right? I'd like to test it > > with this FPGA. How can we do that? (I see that there are synthesized > > netlists on Niktech's website). > > Why bother? There are comparable cores available that fit in an XC3S200, > and for which you get HDL source code, not just a netlist. I completely > fail to understand what MANIK brings to the party.Article: 74807
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:k0qan0pj35a93gnv0muhca7h13ivfntl62@4ax.com... > > They are called "cores". > > >and then put together with an insulation layer in between? > > That is called "prepreg". > > > It might > >be that both sides of the separate boards would have to be the same. > > That is usually the case, although it is possible to build up copper > thickness by plating e.g. the outer layers. > > Regards, > Allan Glen, Allan, For a four layer board, I think it is possible to have a core, with prepreg on either side, overlaid with foil for the outer copper layers. I use something like this in my microvia boards, the prepreg is laserable. Probably more expensive though. As for whether thicker copper is useful on layers inside the board for SI reasons, I expect the limiting factor is the via + track + lead frame inductance to the pad, rather than the plane inductance. Good for thermal reasons though. Cheers, Syms.Article: 74808
Hi Brian,
Comments:-
"Brian Davis" <brimdavis@aol.com> wrote in message
news:a528ffe0.0410191100.7b2c6935@posting.google.com...
> Austin wrote:
> >
> > SSO guidelines are on page 23 of:
> >
> > http://direct.xilinx.com/bvdocs/publications/ds099-3.pdf
> >
> Except for the leaded S3 packages {VQ/TQ/PQ}, which are still
> conspicuously absent from table 23.
>
That's because the lead frame has buggered your SI before you've even
started your PCB.
> Other table 23 oddities:
>
> 1) Why are the SSO pin limits for those spiffy current mode
> differential drivers so low, nearly the same as for the high
> drive single ended I/O standards?
>
> Answer Record 19972 still says "Because the Spartan-3 LVDS
> driver is very balanced, its switching causes a negligible
> amount of transient current. As a result, SSOs are not a problem."
>
> 2) Why are the table 23 SSO limits for the older voltage-mode
> differential output drivers {LVPECL,BLVDS} identical to those
> of the newer current-mode drivers {LVDS,LDT,RSDS} ?
>
The idea is that if the voltage mode drivers switch simultaneously in
opposite directions, the current through the Vcco pins stays constant, so
the lead/trace inductance doesn't screw things up.
> 3) Why do the input-only differential parallel DCI standards
> show up in the SSO table?
>
>
> Brian
Dunno!
Article: 74809Symon wrote: (after I asked about thicker copper on some layers) > For a four layer board, I think it is possible to have a core, with prepreg > on either side, overlaid with foil for the outer copper layers. I use > something like this in my microvia boards, the prepreg is laserable. > Probably more expensive though. > As for whether thicker copper is useful on layers inside the board for SI > reasons, I expect the limiting factor is the via + track + lead frame > inductance to the pad, rather than the plane inductance. Good for thermal > reasons though. The suggestion was to improve the ground plane by making it thicker. To reduce via inductance you need as many of them as you can get. (Inductors in parallel.) The OP wanted a four layer board instead of following the suggested two ground and two power planes. -- glenArticle: 74810
Brian,
See below,
Austin
Brian Davis wrote:
> Austin wrote:
>
>>SSO guidelines are on page 23 of:
>>
>>http://direct.xilinx.com/bvdocs/publications/ds099-3.pdf
>>
>
> Except for the leaded S3 packages {VQ/TQ/PQ}, which are still
> conspicuously absent from table 23.
>
> Other table 23 oddities:
>
> 1) Why are the SSO pin limits for those spiffy current mode
> differential drivers so low, nearly the same as for the high
> drive single ended I/O standards?
>
> Answer Record 19972 still says "Because the Spartan-3 LVDS
> driver is very balanced, its switching causes a negligible
> amount of transient current. As a result, SSOs are not a problem."
LVDS is a low current driver, but the LVPECL is two single ended drivers
with external resistors, so it has significant current.
Even LVDS has a restriction, but not nearly that of a larger driver
(more current). Unless I am missing something?
>
> 2) Why are the table 23 SSO limits for the older voltage-mode
> differential output drivers {LVPECL,BLVDS} identical to those
> of the newer current-mode drivers {LVDS,LDT,RSDS} ?
??? I'll have to ask Steve K.
>
> 3) Why do the input-only differential parallel DCI standards
> show up in the SSO table?
Because they draw current for the parallel termiantion, and the
restriction is for current drain on the Vcco/Gnd pins in the bank.
>
>
> Brian
Article: 74811"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:cl3t0g$qob$1@gnus01.u.washington.edu... > > The suggestion was to improve the ground plane by making it > thicker. To reduce via inductance you need as many of them > as you can get. (Inductors in parallel.) The OP wanted a four > layer board instead of following the suggested two ground and > two power planes. > I just realised, making it thicker will only reduce its resistance. Its inductance won't change. The inductance is determined by the loop area of the current path. Think about it, when you calculate the inductance of a coil, you don't need to know the wire diameter, just the diameter and number of turns. Best, Syms.Article: 74812
I just got my new ISE and went straight to synthesizing some of my old
designs. Basically, I'm planning on publishing soon, and figured the
Virtex-4 would bolster my numbers even further. However, that wasn't
the case.
******************************************************************
******************************************************************
Virtex-4 Timing
******************************************************************
******************************************************************
Timing constraint: Default period analysis for Clock 'clk'
Delay: 3.445ns (Levels of Logic = 0)
Source: ksb10_sb3_Mrom__n00001_inst_ramb_0 (RAM)
Destination: rcx10_t5_25 (FF)
Source Clock: clk rising
Destination Clock: clk rising
Data Path: ksb10_sb3_Mrom__n00001_inst_ramb_0 to rcx10_t5_25
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
RAMB16:CLKA->DOA1 1 1.830 0.470
ksb10_sb3_Mrom__n00001_inst_ramb_0 (t1_9<1>)
FDR:R 1.145 rcx10_t5_25
----------------------------------------
Total 3.445ns (2.975ns logic, 0.470ns route)
(86.4% logic, 13.6% route)
******************************************************************
******************************************************************
Virtex-2 Pro Timing
******************************************************************
******************************************************************
Timing constraint: Default period analysis for Clock 'clk'
Delay: 2.297ns (Levels of Logic = 0)
Source: ksb10_sb3_Mrom__n00001_inst_ramb_0 (RAM)
Destination: rcx10_t5_25 (FF)
Source Clock: clk rising
Destination Clock: clk rising
Data Path: ksb10_sb3_Mrom__n00001_inst_ramb_0 to rcx10_t5_25
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
RAMB16_S36:CLK->DO1 1 1.401 0.360
ksb10_sb3_Mrom__n00001_inst_ramb_0 (t1_9<1>)
FDR:R 0.536 rcx10_t5_25
----------------------------------------
Total 2.297ns (1.937ns logic, 0.360ns route)
(84.3% logic, 15.7% route)
**************************************************************
**************************************************************
...So, you'll notice the critical path is identical in both. However,
it seems flat-out that both the logic and the routing is slower in the
Virtex-4. I'm a little disappointed, as I've heard claims of 500 MHz
all around, and I'm not seeing it. I would've been happy just with
some faster logic, but slower I don't understand.
By the way, this holds across all types of Virtex-4 devices. Among
other architectures of this particular application (encryption)
Virtex-4 is slower. However, I did notice that for my FIR filters and
FFTs I have a huge increase in speed. Am I just out of luck on this
application, or am I missing something?
Article: 74813I wrote: > Why bother? There are comparable cores available that fit in an XC3S200, > and for which you get HDL source code, not just a netlist. "Jaime Andrés Aranguren Cardona" <jaac@nospam.sanjaac.com> writes: > Would you mind to tell me where from? http://www.opencores.org/Article: 74814
On Tue, 19 Oct 2004 14:00:57 -0700, Eric wrote: > I just got my new ISE and went straight to synthesizing some of my old > designs. Basically, I'm planning on publishing soon, and figured the > Virtex-4 would bolster my numbers even further. However, that wasn't > the case. > > ****************************************************************** > ****************************************************************** > Virtex-4 Timing > ****************************************************************** > ****************************************************************** > Timing constraint: Default period analysis for Clock 'clk' > Delay: 3.445ns (Levels of Logic = 0) > Source: ksb10_sb3_Mrom__n00001_inst_ramb_0 (RAM) > Destination: rcx10_t5_25 (FF) > Source Clock: clk rising > Destination Clock: clk rising > > Data Path: ksb10_sb3_Mrom__n00001_inst_ramb_0 to rcx10_t5_25 > Gate Net > Cell:in->out fanout Delay Delay Logical Name (Net Name) > ---------------------------------------- ------------ > RAMB16:CLKA->DOA1 1 1.830 0.470 > ksb10_sb3_Mrom__n00001_inst_ramb_0 (t1_9<1>) > FDR:R 1.145 rcx10_t5_25 > ---------------------------------------- > Total 3.445ns (2.975ns logic, 0.470ns route) > (86.4% logic, 13.6% route) > > ****************************************************************** > ****************************************************************** > Virtex-2 Pro Timing > ****************************************************************** > ****************************************************************** > Timing constraint: Default period analysis for Clock 'clk' > Delay: 2.297ns (Levels of Logic = 0) > Source: ksb10_sb3_Mrom__n00001_inst_ramb_0 (RAM) > Destination: rcx10_t5_25 (FF) > Source Clock: clk rising > Destination Clock: clk rising > > Data Path: ksb10_sb3_Mrom__n00001_inst_ramb_0 to rcx10_t5_25 > Gate Net > Cell:in->out fanout Delay Delay Logical Name (Net Name) > ---------------------------------------- ------------ > RAMB16_S36:CLK->DO1 1 1.401 0.360 > ksb10_sb3_Mrom__n00001_inst_ramb_0 (t1_9<1>) > FDR:R 0.536 rcx10_t5_25 > ---------------------------------------- > Total 2.297ns (1.937ns logic, 0.360ns route) > (84.3% logic, 15.7% route) > > > ************************************************************** > ************************************************************** > > ...So, you'll notice the critical path is identical in both. However, > it seems flat-out that both the logic and the routing is slower in the > Virtex-4. I'm a little disappointed, as I've heard claims of 500 MHz > all around, and I'm not seeing it. I would've been happy just with > some faster logic, but slower I don't understand. > > By the way, this holds across all types of Virtex-4 devices. Among > other architectures of this particular application (encryption) > Virtex-4 is slower. However, I did notice that for my FIR filters and > FFTs I have a huge increase in speed. Am I just out of luck on this > application, or am I missing something? I did some test builds on my InfiniBand cores and I found that the Virtex 4 numbers were better than the V2P number but not by nearly as much as the -speed numbers would indicate. With the V2P20-6 my cores can run upto 133MHz, with the -11 speed of the V4 I was getting 154MHz, the -10 speed was running around 5% faster than the V2P-6. The speed tables that are in the current tools release must be pretty preliminary so we should all take whatever number we are getting with a grain of salt. Never the less it would be nice if Xilinx would try to keep the -speed number reasonably consistant from family to family.Article: 74815
Symon wrote: (snip regarding decreasing inductance by thicker ground planes) > I just realised, making it thicker will only reduce its > resistance. Its inductance won't change. The inductance > is determined by the loop area of the current path. > Think about it, when you calculate the inductance of a > coil, you don't need to know the wire diameter, just the > diameter and number of turns. The coil formula doesn't work so well for a ground plane, but I do think you are right. The volume occupied by flux is staying (about) the same. As a coil is stretched into a straight wire its inducance decreases. Then, as the wire gets larger it also decreases but that is because the field spread out more. I think, though, that more vias still decreases the inductance until they get so close that there is a large field overlap bewteen them. -- glenArticle: 74816
Hi all, I am trying to figure out the pin allocation for a Xilinx Spartan-II device in the PQ208 package that is to implement a PCI agent (target and master). The initial approach was to connect all IOs from banks 6 and 7 and parts of bank 0 and 5 directly with the card edge traces in the order given by the card edge pin assignment. Banks 6 and 7 collectively provide 36 IOs whose supply is provided by 5 Vcco/GND pairs. Given an SSO recommendation of 4 IOs per Vcco/GND pair for PCI, the approach does not seem to be feasable with an example of a master driving a 0xffffffff (that's 32 switching IOs alone for the AD lines) on the bus. Since I believe that it's not the first time that a Spartan is used for PCI agents, how serious are the SSO guide lines to be taken ? Am I overestimating the effects of ground bounce in PCI designs ? Thanks and regards, Christian BoehmeArticle: 74817
> SSO guidelines are on page 23 of: > http://direct.xilinx.com/bvdocs/publications/ds099-3.pdf No data for PQ-208. No data for PCI33_2 or PCI66_3. (Page 25.) There is a note at the end of the table that says: The numbers in this table are recommendations that assume sound board layout practice. But that's hard to test or measure. I'm not trying to pick on Xilinx. Most data sheets I look at don't even have that sort of footnote. But this is a hard problem area. How good does "sound board layout" have to be? How/what would you specify if you were writing the data sheet? If you were on a jury for a big legal battle, how would you decide if a design was "sound" enough? Anybody got PCI running on a PQ-208 with only 4 layers? :) Is that a silly idea? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 74818
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:cl44k8$1qu$1@gnus01.u.washington.edu... > I think, though, that more vias still decreases the > inductance until they get so close that there is a > large field overlap bewteen them. Agreed, as you said earlier "Inductors in parallel". The current is shared between the vias. I think you're right about the total inductance increasing as the two (say) vias get close as well, food for thought. Is that because of the mutual inductance between the two current loops? Time to crack out a text book! An interesting discussion, thanks Glen! Best, Syms.Article: 74819
digari wrote: > i was just looking at virtex and stratix architectures. i observed > that direction of carry chain is bottom to top and direction of shift > chain is top to bottom for virtex devices, whereas it appears that > both are in the same direction in stratix. > > Just wondering if it is just a coincidence or is this intentional? This doesn't address your question, but... Be careful assuming that the shift register chains go top-to-bottom. They don't really. The dedicated routing resources for shift register chains only exist within the boundaries of a CLB. If the shift register chain expands across two CLBs for whatever reason, be it length of the chain or constraints, then the shift chain will have to use general routing resources at the CLB boundary. -DavisArticle: 74820
Jan Bruns wrote: > Hallo, [ snip ] > A more important example is the SRL16 and RAM16X1S primitives. Again, > it's "map" reporting, that SRL16 + RAM16X1S aren't supported on F-LUT > of a slice on SpartanII, although the SpartanII Data Sheet > unmistakeable states: > | In addition to operating as a function generator, each LUT can > | provide a 16 x 1-bit synchronous RAM. [...] > | The Spartan-II LUT can also provide a 16-bit shift register > | that is ideal for capturing high-speed or burst-mode data. > [ snip ] > > Jan Bruns Jan, A LUT RAM can be implemented in the F LUT of a SLICE as long as there is also a LUT RAM in the G LUT of the same SLICE. The F LUT RAM hardware is dependent on the G LUT RAM and can not independently support a LUT RAM. This is true for shift registers as well. -DavisArticle: 74821
Symon wrote:
< re. the missing leaded package SSO data >
>
>That's because the lead frame has buggered your SI before
>you've even started your PCB.
>
Yes, and the poorer on-die power distribution of those
same leadframes makes adhering to those (missing) SSO
guidelines even more important than in the BGA parts.
>
>The idea is that if the voltage mode drivers switch
>simultaneously in opposite directions, the current through
>the Vcco pins stays constant, so the lead/trace inductance
>doesn't screw things up.
>
Xilinx has two flavors of differential driver:
1) the older style, voltage-mode, pseudo-differential,
switch-two-CMOS-outputs-with-an-external-resistive-attenuator
which they say doesn't balance that well :
http://www.fpga-faq.com/archives/42700.html#42709
2) the 'real' balanced current-mode drivers of the V2/V2P/S3,
which the Answer Records say is not a factor in SSO limits
So, I'd expected to see much better SSO numbers for the 'real'
LVDS drivers than for the older 'pretend' ones, but DS099, table 23,
says both types have a four-pair SSO limit per VCCO-GND pair.
Brian
Article: 74822
Austin wrote:
>
>LVDS is a low current driver, but the LVPECL is two single
>ended drivers with external resistors, so it has significant current.
>
>Even LVDS has a restriction, but not nearly that of a
>larger driver (more current). Unless I am missing something?
>
I'd also expected to see much better numbers for the
current-mode drivers, but the Spartan3 SSO table that
you referenced says otherwise:
Excerpts from DS099-3, v1.4, Table 23
SSO outputs per VCCO/GND pair
Single ended:
LVCMOS33 Fast 16mA 7 pins
LVCMOS33 Fast 24mA 3 pins
Current-mode:
LVDS_25 4 pairs (8 pins)
RSDS_25 4 pairs
Psuedo-differential:
BLVDS_25 4 pairs
LVPECL_25 4 pairs
Which lists the current mode LVDS drivers as having the
same low SSO pin limit (4 pairs) as the LVPECL drivers, and
pretty much the same pin limit as does LVCMOS33/FAST/16mA.
>
>>
>> 3) Why do the input-only differential parallel DCI standards
>> show up in the SSO table?
>
>Because they draw current for the parallel termiantion, and the
>restriction is for current drain on the Vcco/Gnd pins in the bank.
>
I'd hoped that was the reason; but since those same "4"'s were
next to every type of differential I/O in the table, I thought it
might be a block pasting error when compiling the datasheet.
Following up on this:
In "normal" operation, these on-chip DCI terminator pairs have
already been biased to 1.25 V, and experience a small balanced
input swing (~0.8V), providing some measure of terminator VCCO
current cancellation.
In this "normal" mode of operation, in the BGA packages,
they have a four pair SSO limit, possibly less for leaded parts.
But at post-configuration DCI startup, these terminators all
switch simultaneously, unbalanced, from full stop to 1.25 V
Given that this unbalanced, larger swing should have poorer SSO
limits than the "normal" operation, that's why I was concerned over
on that other thread about using LVDS_25_DCI in the leaded packages.
Brian
Article: 74823Yes, compiling the library files along with the project is probably a good way to find out the problem. You can do this by the command vlog -y C:/Xilinx/verilog/src/unisims +libext+.v your_DUT.v (if C:/Xilinx is your Xilinx installation directory) and then run the simulation as usual. VikramArticle: 74824
Hi, I am trying to enable commmunication between two FPGAs, both being the Stratix 1S40 on the Nios Stratix Boards. One chip implements a controller while the other implements a datapath. I am trying to provide control signals to the datapath-chip from the controller-chip and retrieve back the output from the datapath-chip back to the controller-chip. For this, I have assigned the outputs and inputs to the pins of the Proto connnectors on the board and used the LVTTL IO standard. For some reason, the communication doesn't seem to take place. Subsequently, the connection between the FPGAs is then done through IDE cables connected to the 40 pin Proto FDCs. Any settings that I should be aware of when attempting to enable communication through Proto connector pins..? Thanks.
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