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
I'm playing with the idea of interfacing a BeagleBone (cheap dual ARM Cortex A8 board) to a Xilinx KC705 Kintex development board. This will give me much more CPU processing power than a microblaze could. I thought I could probably do it with a passive interface because the Kintex can deal with 3.3 Volt I/O. I'd probably use a Xilinx 105 debug board on the FMC HPC connector, and hand build an interface board between the debug board and the BeagleBone. That would leave the LPC connector free for an Avnet HDMI input board (I'm playing around with some video processing / measurement ideas). I would then develop a Angstrom Linux driver for the TI GPMC interface to the Kintex. Anybody see any flaws in this plan? Any advice? Anybody done some / all of this already, and prepared to share so that I don't need to re-invent the wheel? Thanks PeteArticle: 154051
pfraser <pete_fraser@comcast.net> wrote: > I'm playing with the idea of interfacing a BeagleBone > (cheap dual ARM Cortex A8 board) to a Xilinx KC705 > Kintex development board. This will give me much more > CPU processing power than a microblaze could. > I thought I could probably do it with a passive interface > because the Kintex can deal with 3.3 Volt I/O. > I'd probably use a Xilinx 105 debug board on the FMC > HPC connector, and hand build an interface board between > the debug board and the BeagleBone. > That would leave the LPC connector free for an Avnet > HDMI input board (I'm playing around with some video > processing / measurement ideas). > I would then develop a Angstrom Linux driver for > the TI GPMC interface to the Kintex. > Anybody see any flaws in this plan? Any advice? > Anybody done some / all of this already, and prepared > to share so that I don't need to re-invent the wheel? Did you think about the ZYNC and the ZED board (http://www.zedboard.org)? If availability really starts August, you will have much less hassle to start... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 154052
I don't know the status of it, but this is listed in the "Cape Board Registry": http://specialcomp.com/beaglebone/BeagleBone_FPGA.html If you dig into this, please post the status here. BobH On 7/22/2012 1:27 PM, pfraser wrote: > I'm playing with the idea of interfacing a BeagleBone > (cheap dual ARM Cortex A8 board) to a Xilinx KC705 > Kintex development board. This will give me much more > CPU processing power than a microblaze could. > > I thought I could probably do it with a passive interface > because the Kintex can deal with 3.3 Volt I/O. > > I'd probably use a Xilinx 105 debug board on the FMC > HPC connector, and hand build an interface board between > the debug board and the BeagleBone. > > That would leave the LPC connector free for an Avnet > HDMI input board (I'm playing around with some video > processing / measurement ideas). > > I would then develop a Angstrom Linux driver for > the TI GPMC interface to the Kintex. > > Anybody see any flaws in this plan? Any advice? > Anybody done some / all of this already, and prepared > to share so that I don't need to re-invent the wheel? > > Thanks > > Pete >Article: 154053
On Sunday, July 22, 2012 4:27:45 PM UTC-4, pfraser wrote: > I'm playing with the idea of interfacing a BeagleBone > (cheap dual ARM Cortex A8 board) to a Xilinx KC705 > Kintex development board. This will give me much more > CPU processing power than a microblaze could. >=20 > I thought I could probably do it with a passive interface > because the Kintex can deal with 3.3 Volt I/O. >=20 > I'd probably use a Xilinx 105 debug board on the FMC > HPC connector, and hand build an interface board between > the debug board and the BeagleBone. >=20 > That would leave the LPC connector free for an Avnet > HDMI input board (I'm playing around with some video > processing / measurement ideas). >=20 > I would then develop a Angstrom Linux driver for > the TI GPMC interface to the Kintex. >=20 > Anybody see any flaws in this plan? Any advice? > Anybody done some / all of this already, and prepared > to share so that I don't need to re-invent the wheel? >=20 > Thanks >=20 > Pete It seems the BB has a peripheral mux on all the pins so you can wire the FP= GA to the BB in pretty much any pinout and get to any of the peripherals (I= 'm not sure if there are limitations). But I would suggest that you duplic= ate the pinout of the LCD7 which seems to use a parallel interface and you = might be able to reuse some of the driver code. I'm thinking of doing some= thing similar. You might even be able to multiplex the interface and use i= t for both the FPGA board and the LCD7 display. =20 They are doing a 3.5" display, but I don't know if the specs are available = for that yet. They weren't the last time I looked.=20 RickArticle: 154054
On Thursday, July 19, 2012 7:08:50 PM UTC-7, johnp wrote: > I'm looking for a FPGA board that can support HDMI/DVI 1080P in/out. > > I'd like to avoid building my own, I'm probably looking at a volume of 100 units. > > Any thoughts/suggestions? > > Thanks! > > John P Eilert - I think the Atlys/Spartan-6 cannot support a 1080P data rate. The PLL would need to run at about 1.4 GHz for the TMDS serial stream which exceeds the S6 spec. John PArticle: 154055
Am Montag, 23. Juli 2012 05:09:37 UTC+2 schrieb johnp: > On Thursday, July 19, 2012 7:08:50 PM UTC-7, johnp wrote: > > I&#39;m looking for a FPGA board that can support HDMI/DVI 1080P in/out. > > > > I&#39;d like to avoid building my own, I&#39;m probably looking at a volume of 100 units. > > > > Any thoughts/suggestions? > > > > Thanks! > > > > John P > > Eilert - > > I think the Atlys/Spartan-6 cannot support a 1080P data rate. The PLL would need to run at about 1.4 GHz for the TMDS serial stream which exceeds the S6 spec. > > John P Hi John, as it seems, there are only simple LVDS buffers installed on the board. Other boards had some nice HDMI front-end chips installed, which provided the RGB data lines in parallel to the FPGA (Similar chips are available from NS and TI). Maybe you find addon boards with these chips for some std. FPGA board. Have a nice synthesis EilertArticle: 154056
Uwe Bonnes wrote: > Did you think about the ZYNC and the ZED board (http://www.zedboard.org)? > If availability really starts August, you will have much less hassle to > start... I wasn't familiar with that board. It looks interesting, and the price is right. The FPGA is way underpowered for the video processing I would want to do, but perhaps I could use this board instead of the BeagleBone, and couple it to the KC705 with an FMC to FMC cable. That would be a lot simpler mechanically than using the BeagleBone. I had originally intended to use perf board with connectors for the FMC-105-Debug, and headers for the BeagleBone but unfortunately the 105 (which I own) and the similar TED parts (which I don't) have connectors which are not set on 0.1" centers. That means an even worse mechanical kludge. So, in favor of the ZED board is mechanical neatness, and less work hacking up sections of perf board and gluing them together (though I would need to check that I could present the appropriate signals to the ZED board's LPC connector). Also, it's A9 rather than A8. In favor of the BeagleBoard is a reasonably mature Angstom distribution, and a full user community. Who knows what distribution will be available for the ZED board initially? Thanks PeteArticle: 154057
rickman wrote: > But I would suggest that you duplicate the pinout of the LCD7 > which seems to use a parallel interface and you might be able > to reuse some of the driver code. I'm thinking of doing something > similar. You might even be able to multiplex the interface and > use it for both the FPGA board and the LCD7 display. Unfortunately the LCD7 seems to use the TI chip's dedicated 16-bit LCD interface. It looks like it probably uses mux mode 0, so I suspect the GPMC is still available, but they don't seem to use the GPMC. Thanks PeteArticle: 154058
pfraser wrote: > I'm playing with the idea of interfacing a BeagleBone > (cheap dual ARM Cortex A8 board) to a Xilinx KC705 > Kintex development board. This will give me much more > CPU processing power than a microblaze could. > > I thought I could probably do it with a passive interface > because the Kintex can deal with 3.3 Volt I/O. I did this with the older Beagle Board, where the I/O is 1.8 V. I set up a Spartan 3AN FPGA with one bank at 1.8 V to interface to the Beagle, and the other 3 banks at 3.3 V for outside I/O. It is working quite nicely. If you have not dealt with user level to GPIO on the ARM processors, it is a bit complex, as there are multiplexers to swap various I/O devices onto the limited package pins. Then you set up memory mapping pointers to the GPIO registers, and you have to carefully mask off the pins that are in use by other parts of the system. JonArticle: 154059
BobH wrote: > I don't know the status of it, but this is listed in the "Cape Board > Registry": http://specialcomp.com/beaglebone/BeagleBone_FPGA.html But, does it really exist? Looks like a rendered drawing (although it sure fooled ME!) and no update since November, "PCB design almost ready". JonArticle: 154060
rickman wrote: > > It seems the BB has a peripheral mux on all the pins so you can wire the > FPGA to the BB in pretty much any pinout and get to any of the peripherals > (I'm not sure if there are limitations). There are MANY limitations. Each peripheral device can be mapped to up to 4 package pads, but not "any pinout". So, many peripherals are not available because the pads you need are not wired out, or are being used by something necessary. JonArticle: 154061
On Monday, July 23, 2012 2:47:57 PM UTC-4, pfraser wrote: > rickman wrote: > > But I would suggest that you duplicate the pinout of the LCD7 > > which seems to use a parallel interface and you might be able > > to reuse some of the driver code. I'm thinking of doing somethi= ng > > similar. You might even be able to multiplex the interface and > > use it for both the FPGA board and the LCD7 display. >=20 > Unfortunately the LCD7 seems to use the TI chip's dedicated > 16-bit LCD interface. It looks like it probably uses mux mode 0, > so I suspect the GPMC is still available, but they don't seem > to use the GPMC. >=20 > Thanks >=20 > Pete Funny, I get more info on the Beagle boards here than I ever have in the Be= agle google group. The guy running the thing just says to read the documen= tation and not many others respond. I have found the BB to be a bit diffic= ult to even find info on other than the chip data sheet. =20 RickArticle: 154062
On 7/23/2012 12:01 PM, Jon Elson wrote: > BobH wrote: > >> I don't know the status of it, but this is listed in the "Cape Board >> Registry": http://specialcomp.com/beaglebone/BeagleBone_FPGA.html > But, does it really exist? Looks like a rendered drawing (although it sure > fooled ME!) and no update since November, "PCB design almost ready". I have the same question, that was why I highlighted the possible vaporousness of it. If it exists, it could be a nice piece to play with. BobHArticle: 154063
On 7/23/2012 12:03 PM, Jon Elson wrote: >> rickman wrote: >> It seems the BB has a peripheral mux on all the pins so you can wire the >> FPGA to the BB in pretty much any pinout and get to any of the peripherals >> (I'm not sure if there are limitations). > There are MANY limitations. Each peripheral device can be mapped to > up to 4 package pads, but not "any pinout". So, many peripherals are not > available because the pads you need are not wired out, or are being used > by something necessary. Also, a number of the pins on the device are not brought out to the expansion connectors, further limiting the choices. I just went through the exercise of selecting pins for a board I am working on. BobHArticle: 154064
BobH wrote: > I have the same question, that was why I highlighted the possible > vaporousness of it. If it exists, it could be a nice piece to play with. > I emailed them, but no reply yet.Article: 154065
rickman wrote: > > Funny, I get more info on the Beagle boards here than I ever have in the Beagle google group. The guy running the thing just says to read the documentation and not many others respond. I have found the BB to be a bit difficult to even find info on other than the chip data sheet. I haven't tried the Beagle group yet. I feel a bit guilty starting this thread in an FPGA group, when there isn't much discussion of FPGAs, but at least it isn't the most off-topic thread I've seen. Maybe if I insert a bit of an FPGA question: It looks from the manual that I should be able to configure the FMC interface of the KC705 to run at 3.3V (through the use of Vadj), and that the Avnet DVI I/O FMC Module should be fine with that. Can anybody verify that it should be OK? PeteArticle: 154066
Hello all. I have a very strange thing happening with my FPGA. I have Xilinx Spartan-3E FPGA, that I am programming to count external pulses in 1us time bins. The way I'm doing that, is I have a pulse index counter, that increments whenever there's a rising edge on the pulse counter. (No resetting, no enabling, etc.) Then I have another loop that checks the count on the pulse counter every 1us, and writes the "pulse index" to an off-board SDRAM chip. So I have an always block like this: always @(posedge pulse_in) begin pulse_index <= pulse_index + 1; end This works fine 99.9% of the time, but about 100-200 times out of a 1,000,000 time bins, the "pulse index" decreases between consecutive time bins. For example, it could go from 195 to 194. This does not seem to be related to the counter being full either (for example reaching 255 on a 8-bit counter), because this happens with different counter sizes, and it happens near the mid range of the counter value. Anyone have any idea what might be happening? I suspect some sort of hardware-related issue, e.g. the pulses I am inputting is not clean enough. Some facts: 1. The number of errors seem to be roughly proportional the input pulse rate. So if I send 2MHz instead of 1MHz, I get roughly twice the number of errors. 2. The value of "pulse_index" does not go directly into the SDRAM. The value is written to a different register every 1us, which is written into a FIFO, which finally goes into the SDRAM. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154067
On 7/26/2012 11:09 AM, yhs2012 wrote: > Hello all. I have a very strange thing happening with my FPGA. > > I have Xilinx Spartan-3E FPGA, that I am programming to count external > pulses in 1us time bins. The way I'm doing that, is I have a pulse index > counter, that increments whenever there's a rising edge on the pulse > counter. (No resetting, no enabling, etc.) Then I have another loop that > checks the count on the pulse counter every 1us, and writes the "pulse > index" to an off-board SDRAM chip. > > So I have an always block like this: > > always @(posedge pulse_in) begin > pulse_index <= pulse_index + 1; > end > > This works fine 99.9% of the time, but about 100-200 times out of a > 1,000,000 time bins, the "pulse index" decreases between consecutive time > bins. For example, it could go from 195 to 194. This does not seem to be > related to the counter being full either (for example reaching 255 on a > 8-bit counter), because this happens with different counter sizes, and it > happens near the mid range of the counter value. > > Anyone have any idea what might be happening? I suspect some sort of > hardware-related issue, e.g. the pulses I am inputting is not clean > enough. > > Some facts: > 1. The number of errors seem to be roughly proportional the input pulse > rate. So if I send 2MHz instead of 1MHz, I get roughly twice the number of > errors. > > 2. The value of "pulse_index" does not go directly into the SDRAM. The > value is written to a different register every 1us, which is written into a > FIFO, which finally goes into the SDRAM. Is the input pulse that you are measuring synchronized to the clock that you are using for the rest of the logic? If it is not synchronized, you will get timing violations occasionally. Counters can behave unpredictably with timing violations because different bits in the counter may have different delays due to placement and routing differences. Look up de-metastabilization for more info. Good Luck, BobHArticle: 154068
yhs2012 <3610@embeddedrelated> wrote: > Hello all. I have a very strange thing happening with my FPGA. > I have Xilinx Spartan-3E FPGA, that I am programming to count external > pulses in 1us time bins. The way I'm doing that, is I have a pulse index > counter, that increments whenever there's a rising edge on the pulse > counter. (No resetting, no enabling, etc.) Then I have another loop that > checks the count on the pulse counter every 1us, and writes the "pulse > index" to an off-board SDRAM chip. This problem is well known. The usual solution is to use a gray-code counter. The problem comes when you latch the value while it is changing, and one changes (or has routing delay) different from the other. Gray code only changes one bit on each count, such that you always get one value or the next. -- glenArticle: 154069
Problem solved! I used a gray counter and I am getting no errors so far. Thanks so much for your help guys. You guys rock! >yhs2012 <3610@embeddedrelated> wrote: >> Hello all. I have a very strange thing happening with my FPGA. > >> I have Xilinx Spartan-3E FPGA, that I am programming to count external >> pulses in 1us time bins. The way I'm doing that, is I have a pulse index >> counter, that increments whenever there's a rising edge on the pulse >> counter. (No resetting, no enabling, etc.) Then I have another loop that >> checks the count on the pulse counter every 1us, and writes the "pulse >> index" to an off-board SDRAM chip. > >This problem is well known. The usual solution is to use a >gray-code counter. > >The problem comes when you latch the value while it is changing, >and one changes (or has routing delay) different from the other. > >Gray code only changes one bit on each count, such that you >always get one value or the next. > >-- glen > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154070
Hi, I've recently started to use the Xilinx EDK tools to create a system in whi= ch there are two AXI masters. I made these masters and then imported them u= sing the Xilinx EDK IP tool so that they would fit the AXI standard. Howeve= r when I tried compiling my design, EDK fails at the mapping stage and give= s these errors.=20 ERROR:MapLib:979 - LUT3 symbol ERROR:MapLib:979 - LUT3 symbol ERROR:MapLib:979 - LUT6 symbol ERROR:MapLib:978 - LUT3 symbol ERROR:MapLib:978 - LUT6 symbol Interestingly when I change my IP to an AXI Lite Master and comment out the= signals which are not used in AXI Lite, the design will compile. Does anyo= ne have any ideas on what may be causing this issue? and how I may be able = to resolve it? Thank you for reading my query.Article: 154071
If I use the core generator to generate an IBERT for a Spartan 6 and try to=
implement the example design the errors I'm getting I'm not understanding.=
I'm assuming I'm not understanding the back box portion of the example des=
ign. Module S6chipscope_ibert.v is in the project. Thanks in advance... He=
re are the errors, followed by the example design:
ERROR:NgdBuild:604 - logical block 'U_S6CHIPSCOPE_IBERT' with type
'S6chipscope_ibert' could not be resolved. A pin name misspelling can ca=
use
this, a missing edif or ngc file, case mismatch between the block name a=
nd
the edif or ngc file name, or the misspelling of a type name. Symbol
'S6chipscope_ibert' is not supported in target 'spartan6'.
ERROR:NgdBuild:604 - logical block 'U_ICON' with type 'chipscope_icon' coul=
d not
be resolved. A pin name misspelling can cause this, a missing edif or ng=
c
file, case mismatch between the block name and the edif or ngc file name=
, or
the misspelling of a type name. Symbol 'chipscope_icon' is not supported=
in
target 'spartan6'.
`timescale 1ns / 1ps
//***************************** Module ****************************
module example_S6chipscope_ibert
(
//Input Declarations
input GTP0_X0_Y0_RX_P_IPAD,
input GTP0_X0_Y0_RX_N_IPAD,
input GTP1_X0_Y0_RX_P_IPAD,
input GTP1_X0_Y0_RX_N_IPAD,
input SYSCLOCK_P_IPAD,
input SYSCLOCK_N_IPAD,
input REFCLK0_X0Y0_P_IPAD,
input REFCLK0_X0Y0_N_IPAD,
//Output Decalarations
output GTP0_X0_Y0_TX_P_OPAD,
output GTP0_X0_Y0_TX_N_OPAD,
output GTP1_X0_Y0_TX_P_OPAD,
output GTP1_X0_Y0_TX_N_OPAD
);
//local signals declaration
wire refclk0_x0y0_i;
wire ibert_sysclock;
wire [35:0] CONTROL0;
// Ibert Core Wrapper Instance
S6chipscope_ibert U_S6CHIPSCOPE_IBERT
(
.GTP0_X0_Y0_TX_P_OPAD(GTP0_X0_Y0_TX_P_OPAD),
.GTP0_X0_Y0_TX_N_OPAD(GTP0_X0_Y0_TX_N_OPAD),
.GTP1_X0_Y0_TX_P_OPAD(GTP1_X0_Y0_TX_P_OPAD),
.GTP1_X0_Y0_TX_N_OPAD(GTP1_X0_Y0_TX_N_OPAD),
.GTP0_X0_Y0_RX_P_IPAD(GTP0_X0_Y0_RX_P_IPAD),
.GTP0_X0_Y0_RX_N_IPAD(GTP0_X0_Y0_RX_N_IPAD),
.GTP1_X0_Y0_RX_P_IPAD(GTP1_X0_Y0_RX_P_IPAD),
.GTP1_X0_Y0_RX_N_IPAD(GTP1_X0_Y0_RX_N_IPAD),
.REFCLK0_X0Y0_I(refclk0_x0y0_i),
.CONTROL(CONTROL0),
.SYSCLOCK_I(ibert_sysclock)
);
chipscope_icon U_ICON
(
.CONTROL0(CONTROL0));
// GT Refclock Instances
=20
IBUFDS U_TILE0_REFCLK0
(
.O(refclk0_x0y0_i),
.I(REFCLK0_X0Y0_P_IPAD),
.IB(REFCLK0_X0Y0_N_IPAD)
);
=20
=20
// Sysclock Source
IBUFDS U_SYSCLOCK_IBUFDS
(
.O(ibert_sysclock),
.I(SYSCLOCK_P_IPAD),
.IB(SYSCLOCK_N_IPAD)
);
endmodule
// Black box declaration
module S6chipscope_ibert
(
output GTP0_X0_Y0_TX_P_OPAD,
output GTP0_X0_Y0_TX_N_OPAD,
output GTP1_X0_Y0_TX_P_OPAD,
output GTP1_X0_Y0_TX_N_OPAD,
input GTP0_X0_Y0_RX_P_IPAD,
input GTP0_X0_Y0_RX_N_IPAD,
input GTP1_X0_Y0_RX_P_IPAD,
input GTP1_X0_Y0_RX_N_IPAD,
input REFCLK0_X0Y0_I,
inout [35:0] CONTROL,
input SYSCLOCK_I
);
endmodule
module chipscope_icon
(
inout [35:0] CONTROL0);
endmodule
Article: 154072On 7/28/2012 5:39 PM, pminmo@gmail.com wrote: > If I use the core generator to generate an IBERT for a Spartan 6 and try to implement the example design the errors I'm getting I'm not understanding. I'm assuming I'm not understanding the back box portion of the example design. Module S6chipscope_ibert.v is in the project. Thanks in advance... Here are the errors, followed by the example design: > > ERROR:NgdBuild:604 - logical block 'U_S6CHIPSCOPE_IBERT' with type > 'S6chipscope_ibert' could not be resolved. A pin name misspelling can cause > this, a missing edif or ngc file, case mismatch between the block name and > the edif or ngc file name, or the misspelling of a type name. Symbol > 'S6chipscope_ibert' is not supported in target 'spartan6'. > ERROR:NgdBuild:604 - logical block 'U_ICON' with type 'chipscope_icon' could not > be resolved. A pin name misspelling can cause this, a missing edif or ngc > file, case mismatch between the block name and the edif or ngc file name, or > the misspelling of a type name. Symbol 'chipscope_icon' is not supported in > target 'spartan6'. > Do you have the .ngc file for the ibert module in the project directory? It contains the actual module guts. Good Luck, BobHArticle: 154073
On Sunday, July 29, 2012 12:56:32 PM UTC-5, BobH wrote: > On 7/28/2012 5:39 PM, pminmo@gmail.com wrote: >=20 > > If I use the core generator to generate an IBERT for a Spartan 6 and tr= y to implement the example design the errors I'm getting I'm not understand= ing. I'm assuming I'm not understanding the back box portion of the example= design. Module S6chipscope_ibert.v is in the project. Thanks in advance..= . Here are the errors, followed by the example design: >=20 > > >=20 > > ERROR:NgdBuild:604 - logical block 'U_S6CHIPSCOPE_IBERT' with type >=20 > > 'S6chipscope_ibert' could not be resolved. A pin name misspelling c= an cause >=20 > > this, a missing edif or ngc file, case mismatch between the block n= ame and >=20 > > the edif or ngc file name, or the misspelling of a type name. Symbo= l >=20 > > 'S6chipscope_ibert' is not supported in target 'spartan6'. >=20 > > ERROR:NgdBuild:604 - logical block 'U_ICON' with type 'chipscope_icon' = could not >=20 > > be resolved. A pin name misspelling can cause this, a missing edif = or ngc >=20 > > file, case mismatch between the block name and the edif or ngc file= name, or >=20 > > the misspelling of a type name. Symbol 'chipscope_icon' is not supp= orted in >=20 > > target 'spartan6'. >=20 > > >=20 >=20 >=20 > Do you have the .ngc file for the ibert module in the project directory?= =20 >=20 > It contains the actual module guts. >=20 >=20 >=20 > Good Luck, >=20 > BobH Yes, I've tried the ngc file(s) with no luck.Article: 154074
Hello, I'm looking for a way to manually change interconnect switch connections. I'm trying to simulate random bit-flips to test my solution for switch-based SEU detection. However, I'm at a loss in my search for viable options. Altera: The chip planner is capable of ECOs, but theey only act on atoms (LEs, and LABs) Xilinx: The FGPA editor showed a bit of promise. I can add connections inside their switchboxes, but all the work has to be done in GUI. I can't extract files to be parsed by homebrew tools. Academic tools: I've tried VPR 6.0, but it shows nothing on switches. Any suggestions to this predicament?
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