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
abirov@gmail.com wrote: > I bought HDMI extender over optical fiber for $125, from Alibaba. > > HDMI Extender works well when Source is my laptop, but when source is my > FPGA board,there is a problem. I enabled TMDS, HPD, DDC, 5+, ground as in > Hamsterwork's project , it doesnot works,I dont know why? Who had the > same situation ? What to do ? It might not support EDID, or might not safely transmit it over a long distance. Result is that the source can't detect what resolution to send. You can either disable EDID in your project, or use an EDID emulator: https://www.aliexpress.com/item/FUERAN-HDMI-Pass-Through-EDID-Emulator-for-use-with-video-splitters-Switches-and-Extenders/32814829516.html? (no idea if that particular one is any good) - with those, there's a way to 'train' them where you plug in the display directly and teach it the EDID, which the emulator replays when it's at the far end of the extender and the EDID can't be read. Alternatively just send a fixed resolution like 640x480 without trying to detect what the far end wants. TheoArticle: 160676
Hi all!
I'm having a problem with the synthesis and P&R tools introducing a
unnecessary gate in a critical path. Consider the following verilog:
reg [31:0] mem_dataintomem = 32'd0;
always @(posedge CLK)
begin
if (mcu_active && (w_we_recv || w_tlb_recv))
mem_dataintomem <= w_data_recv;
if (mem_ack && !mcu_active)
mem_dataintomem <= 0;
end
Practically, the synthesis correctly implements mem_dataintomem as a
register whose data input is ungated w_data_recv, and whose clock enable
and synchronous reset control the contents of the register.
In this setup, for speed considerations, the best thing to do is create a
single gate signal to the clock enable input of a register, and another
separate single gate signal to drive the synchronous reset of the same
register.
But instead, the tools combine the signals, so that there is one single-
gate signal that feeds the synchronous reset, but is also piped into the
other signal (which therefore becomes a two-gate signal). Sort of like
this:
assign ctrl_syn_reset = mem_ack && !mcu_active;
assign ctrl_clock_enable = mcu_active &&
(w_we_recv || w_tlb_recv) &&
!ctrl_syn_reset; // this is superfluous
register_module mem_dataintomem_somebit(
.CLOCK(CLK),
.DATAIN(w_data_recv),
.CLOCK_ENABLE(ctrl_clock_enable),
.RESET(ctrl_syn_reset), // ignore the drive-high-to-reset quirk
[...]
);
My problem is that in this setup ctrl_clock_enable becomes too slow on
account of the extra gate and timing analysis fails.
What I would like is help figuring out some incantation that would make
the machine see the light and not chain the signals. OTOH, is there a
real need for this? It seems obvious to me that only one of CLOCK_ENABLE
or RESET will ever be asserted, and that you don't have to mix them.
I know for a fact I can sidestep the problem if I remove the clock enable
and instead gate the input to the register, but that is *very*
problematic because that area of the die is already tightly packed and it
can't support the extra logic (that is, all the wires are already taken).
The chip used is Lattice iCE40 HX8K, and the software used is iCEcube2
version 2017.01.27914 . Synthesis is performed by the bundled Synplify
Pro L-2016.09.L+ice40, build 077R.
The code is part of a FOSH project and can be inspected on
https://github.com/akuktin/special_snowflake . The code of interest for
this question is in file cache/cpu_mcu2.v, lines approximately 303 to
333. The code at the start of the post (without else) is one of the
experiments I tried, and failed with.
Article: 160677
On Saturday, 9/22/2018 9:03 PM, Aleksandar Kuktin wrote:
> Hi all!
>
> I'm having a problem with the synthesis and P&R tools introducing a
> unnecessary gate in a critical path. Consider the following verilog:
>
> reg [31:0] mem_dataintomem = 32'd0;
>
> always @(posedge CLK)
> begin
> if (mcu_active && (w_we_recv || w_tlb_recv))
> mem_dataintomem <= w_data_recv;
> if (mem_ack && !mcu_active)
> mem_dataintomem <= 0;
> end
>
> Practically, the synthesis correctly implements mem_dataintomem as a
> register whose data input is ungated w_data_recv, and whose clock enable
> and synchronous reset control the contents of the register.
>
> In this setup, for speed considerations, the best thing to do is create a
> single gate signal to the clock enable input of a register, and another
> separate single gate signal to drive the synchronous reset of the same
> register.
>
> But instead, the tools combine the signals, so that there is one single-
> gate signal that feeds the synchronous reset, but is also piped into the
> other signal (which therefore becomes a two-gate signal). Sort of like
> this:
>
> assign ctrl_syn_reset = mem_ack && !mcu_active;
> assign ctrl_clock_enable = mcu_active &&
> (w_we_recv || w_tlb_recv) &&
> !ctrl_syn_reset; // this is superfluous
> register_module mem_dataintomem_somebit(
> .CLOCK(CLK),
> .DATAIN(w_data_recv),
> .CLOCK_ENABLE(ctrl_clock_enable),
> .RESET(ctrl_syn_reset), // ignore the drive-high-to-reset quirk
> [...]
> );
>
> My problem is that in this setup ctrl_clock_enable becomes too slow on
> account of the extra gate and timing analysis fails.
>
> What I would like is help figuring out some incantation that would make
> the machine see the light and not chain the signals. OTOH, is there a
> real need for this? It seems obvious to me that only one of CLOCK_ENABLE
> or RESET will ever be asserted, and that you don't have to mix them.
>
> I know for a fact I can sidestep the problem if I remove the clock enable
> and instead gate the input to the register, but that is *very*
> problematic because that area of the die is already tightly packed and it
> can't support the extra logic (that is, all the wires are already taken).
>
> The chip used is Lattice iCE40 HX8K, and the software used is iCEcube2
> version 2017.01.27914 . Synthesis is performed by the bundled Synplify
> Pro L-2016.09.L+ice40, build 077R.
>
> The code is part of a FOSH project and can be inspected on
> https://github.com/akuktin/special_snowflake . The code of interest for
> this question is in file cache/cpu_mcu2.v, lines approximately 303 to
> 333. The code at the start of the post (without else) is one of the
> experiments I tried, and failed with.
>
If the synthesizer is using a simple template approach to generating
the reset and clock control signal, it would probably be best to code
your logic the way the template expects it, typically:
always @ (posedge clk)
if (reset condition)
reset actions
else if (enable condition)
enable actions
Logically this is the same as what you've written, but the template
fits the expectations of the synthesizer better.
--
Gabor
Article: 160678Thank you guys, especially thanx to Theo Markettos! in 480P it works. I want it work on 1080p, could someone help to find it ?Article: 160679
Thank you guys, especially thanx to Theo Markettos! in 480P it works. I want it work on 1080p, could someone help to find VHDL code for DDC ?Article: 160680
abirov@gmail.com wrote: > Thank you guys, especially thanx to Theo Markettos! in 480P it works. > > I want it work on 1080p, could someone help to find it ? So just try sending 1080p without trying to probe the EDID? If you need timings, 'cvt' is a handy tool to generate standard modes: (you can look up what each column means) $ cvt 1920 1080 # 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync TheoArticle: 160681
tomorrow from 20:15 cet until open end live on my channel https://www.twitch.tv/fpga_guru schematic design on fpga. check it outArticle: 160682
On Tuesday, September 25, 2018 at 6:18:54 PM UTC+6, Theo Markettos wrote: > abirov@gmail.com wrote: > > Thank you guys, especially thanx to Theo Markettos! in 480P it works. > > > > I want it work on 1080p, could someone help to find it ? > > So just try sending 1080p without trying to probe the EDID? > > If you need timings, 'cvt' is a handy tool to generate standard modes: > (you can look up what each column means) > > $ cvt 1920 1080 > # 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz > Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync > > Cannot transmit 1080p but with 150MHZ, cannot generate 1080p with 173MHZ HDMIArticle: 160683
On 28/09/2018 00:55, olli22221@web.de wrote: > tomorrow from 20:15 cet until open end live on my channel > > https://www.twitch.tv/fpga_guru > > schematic design on fpga. check it out > You could do that over 30 years ago with the DOS version of Altera MaxPlus .... What's new???Article: 160684
On 28/09/18 20:48, Andy Bennet wrote: > On 28/09/2018 00:55, olli22221@web.de wrote: >> tomorrow from 20:15 cet until open end live on my channel >> >> https://www.twitch.tv/fpga_guru >> >> schematic design on fpga. check it out >> > > You could do that over 30 years ago with the DOS version of Altera > MaxPlus .... > What's new??? The self-called FPGA-guru... is probably the same that has a web page with the same misleading nameArticle: 160685
On Sun, 23 Sep 2018 01:03:30 +0000, Aleksandar Kuktin wrote: > The chip used is Lattice iCE40 HX8K, [...] Okay, I figured it out. The flip-flop is behaving differently than my expectations. Specifically, I had assumed the synchronous reset is fully independent and will have its effect if it is independently asserted during the clock edge. In actual fact, iCE40's synchronous reset only takes effect if the clock_enable is also asserted. So, to reset the flip-flop, you have to assert BOTH reset and clock_enable. Therefore, the extra wire.Article: 160686
> What do you think? That's good stuff. I wonder why you think using a BRAM is bad? It's good = to use the hard cores in an FPGA instead of the fabric--it's less power and= deterministic routing times. Is the CORDIC still advantageous in a modern FPGA? The last time I needed = to find sine, I used a coarse BRAM lookup that output sine on one port and = cos on another. Those were used as derivatives for a 2nd-order Taylor. Tw= o multipliers (more hard cores) are used (using Horner's Rule) for the 1st = and 2nd-order interpolations. I don't remember how many digits of accuracy= this yields, but the latency is low.Article: 160687
Le mercredi 10 octobre 2018 21:52:06 UTC-4, Kevin Neilson a =C3=A9crit=C2= =A0: > > What do you think? >=20 > That's good stuff. I wonder why you think using a BRAM is bad? It's goo= d to use the hard cores in an FPGA instead of the fabric--it's less power a= nd deterministic routing times. >=20 > Is the CORDIC still advantageous in a modern FPGA? The last time I neede= d to find sine, I used a coarse BRAM lookup that output sine on one port an= d cos on another. Those were used as derivatives for a 2nd-order Taylor. = Two multipliers (more hard cores) are used (using Horner's Rule) for the 1s= t and 2nd-order interpolations. I don't remember how many digits of accura= cy this yields, but the latency is low. Cordic is useful to compute high-precision atan2. Otherwise for 2 16-bit i= nputs, you'd need a ram with 2^32 addresses (maybe 16 times less if you tak= e advantage of the symmetries).Article: 160688
> Cordic is useful to compute high-precision atan2. Otherwise for 2 16-bit inputs, you'd need a ram with 2^32 addresses (maybe 16 times less if you take advantage of the symmetries). I think you missed the part about the Taylor interpolation.Article: 160689
On Thursday, October 11, 2018 at 7:37:37 AM UTC-6, Benjamin Couillard wrote= : > Cordic is useful to compute high-precision atan2. Otherwise for 2 16-bit= inputs, you'd need a ram with 2^32 addresses (maybe 16 times less if you t= ake advantage of the symmetries). Sorry; I didn't see that you were talking about arctan. It's not quite as = easy as sin/cos, but there is still the question as to whether a Farrow-typ= e architecture using a coarse lookup and Taylor interpolations would be bet= ter than a CORDIC, and I am guessing that with the BRAMs and multipliers in= present-day FPGAs, the answer would be yes. =20Article: 160690
Le vendredi 12 octobre 2018 00:42:18 UTC-4, Kevin Neilson a =C3=A9crit=C2= =A0: > On Thursday, October 11, 2018 at 7:37:37 AM UTC-6, Benjamin Couillard wro= te: >=20 > > Cordic is useful to compute high-precision atan2. Otherwise for 2 16-b= it inputs, you'd need a ram with 2^32 addresses (maybe 16 times less if you= take advantage of the symmetries). >=20 > Sorry; I didn't see that you were talking about arctan. It's not quite a= s easy as sin/cos, but there is still the question as to whether a Farrow-t= ype architecture using a coarse lookup and Taylor interpolations would be b= etter than a CORDIC, and I am guessing that with the BRAMs and multipliers = in present-day FPGAs, the answer would be yes. Yes I think you're right it could work for an atan or atan 2. You could im= plemented a divider for atan 2 (y/x), a sign look-up (to get the whole 360 = degrees), a BRAM + taylor interpolation.=20 For atan, you'd simply skip the divider and sign look-up part.=20 On the other hand, Xilinx and Altera offer plug-and-play Cordic cores for a= tan/atan2.Article: 160691
> Yes I think you're right it could work for an atan or atan 2. You could = implemented a divider for atan 2 (y/x), a sign look-up (to get the whole 36= 0 degrees), a BRAM + taylor interpolation.=20 >=20 > For atan, you'd simply skip the divider and sign look-up part.=20 >=20 > On the other hand, Xilinx and Altera offer plug-and-play Cordic cores for= atan/atan2. It's probably better to multiply y/x by x to get a normalized ratio rather= than use a divider, which requires a lot of resources. I recalled that I had to implement the atan2 function once for a QAM carrie= r/symbol recovery circuit. I didn't need great precision, so I split one q= uadrant into a grid and put the angle of the center of each grid square int= o a 2-dimensional lookup ROM. Then I could put X,Y into the ROM and get th= e coarse angle (which was then adjusted for the quadrant) and could use tha= t for carrier recovery.Article: 160692
Le mardi 16 octobre 2018 22:36:56 UTC-4, Kevin Neilson a =C3=A9crit=C2=A0: > > Yes I think you're right it could work for an atan or atan 2. You coul= d implemented a divider for atan 2 (y/x), a sign look-up (to get the whole = 360 degrees), a BRAM + taylor interpolation.=20 > >=20 > > For atan, you'd simply skip the divider and sign look-up part.=20 > >=20 > > On the other hand, Xilinx and Altera offer plug-and-play Cordic cores f= or atan/atan2. >=20 > It's probably better to multiply y/x by x to get a normalized ratio rath= er than use a divider, which requires a lot of resources. >=20 > I recalled that I had to implement the atan2 function once for a QAM carr= ier/symbol recovery circuit. I didn't need great precision, so I split one= quadrant into a grid and put the angle of the center of each grid square i= nto a 2-dimensional lookup ROM. Then I could put X,Y into the ROM and get = the coarse angle (which was then adjusted for the quadrant) and could use t= hat for carrier recovery. One case that comes to mind : you have 2 quadrature signals x =3D A(t) * cos (wt + some phase) + noise_x y =3D A(t) * sin (wt + some phase) + noise_y Atan2(y, x) =3D wt + some phase. The variations of A(t) (as long as they a= re slow-ish) will cancel each other out. You can filter or average wt + some phase to extract the phase. Or derivate= "wt + some phase" then filter to get the filtered frequency. So multiplying "y/x by x" would not make much sense in this case.=20Article: 160693
I was wondering what the barriers are to new companies marketing FPGAs. So= me of the technological barriers are obvious. Designing a novel device is = not so easy as the terrain is widely explored, so I expect any new player w= ould need to find a niche application of an unexplored technological featur= e. =20 Silicon Blue exploited a low power technology optimized for low cost device= s in mobile applications. They were successful enough to be bought by Latt= ice and are still in production with the product line expanded considerably= . =20 I believe Achronix started out with the idea of asynchronous logic. I'm no= t clear if they continue to use that or not, but it is not apparent from th= eir web site. Their target is ultra fast clock speeds enabling FPGAs in ne= w market. I don't see then showing up on FPGA vendor lists so I assume the= y are sill pretty low volume.=20 Tabula was based on 3D technology, but they don't appear to have lasted. I= believe they were also claiming an ability to reconfigure logic in real ti= me which sounds like a very complex technology to master. Not sure what ma= rket they were targeting.=20 Other than the technologies, what other barriers do new FPGA companies face= ?=20 Rick C.Article: 160694
torsdag den 18. oktober 2018 kl. 17.22.47 UTC+2 skrev gnuarm.del...@gmail.c= om: > I was wondering what the barriers are to new companies marketing FPGAs. = Some of the technological barriers are obvious. Designing a novel device i= s not so easy as the terrain is widely explored, so I expect any new player= would need to find a niche application of an unexplored technological feat= ure. =20 >=20 > Silicon Blue exploited a low power technology optimized for low cost devi= ces in mobile applications. They were successful enough to be bought by La= ttice and are still in production with the product line expanded considerab= ly. =20 >=20 > I believe Achronix started out with the idea of asynchronous logic. I'm = not clear if they continue to use that or not, but it is not apparent from = their web site. Their target is ultra fast clock speeds enabling FPGAs in = new market. I don't see then showing up on FPGA vendor lists so I assume t= hey are sill pretty low volume.=20 >=20 > Tabula was based on 3D technology, but they don't appear to have lasted. = I believe they were also claiming an ability to reconfigure logic in real = time which sounds like a very complex technology to master. Not sure what = market they were targeting.=20 >=20 > Other than the technologies, what other barriers do new FPGA companies fa= ce?=20 >=20 > Rick C. I'd think patents and the huge task of making the software for itArticle: 160695
On Wednesday, October 17, 2018 at 9:26:38 AM UTC-6, Benjamin Couillard wrot= e: > Le mardi 16 octobre 2018 22:36:56 UTC-4, Kevin Neilson a =C3=A9crit=C2=A0= : > > > Yes I think you're right it could work for an atan or atan 2. You co= uld implemented a divider for atan 2 (y/x), a sign look-up (to get the whol= e 360 degrees), a BRAM + taylor interpolation.=20 > > >=20 > > > For atan, you'd simply skip the divider and sign look-up part.=20 > > >=20 > > > On the other hand, Xilinx and Altera offer plug-and-play Cordic cores= for atan/atan2. > >=20 > > It's probably better to multiply y/x by x to get a normalized ratio ra= ther than use a divider, which requires a lot of resources. > >=20 > > I recalled that I had to implement the atan2 function once for a QAM ca= rrier/symbol recovery circuit. I didn't need great precision, so I split o= ne quadrant into a grid and put the angle of the center of each grid square= into a 2-dimensional lookup ROM. Then I could put X,Y into the ROM and ge= t the coarse angle (which was then adjusted for the quadrant) and could use= that for carrier recovery. >=20 > One case that comes to mind : you have 2 quadrature signals >=20 > x =3D A(t) * cos (wt + some phase) + noise_x > y =3D A(t) * sin (wt + some phase) + noise_y >=20 > Atan2(y, x) =3D wt + some phase. The variations of A(t) (as long as they= are slow-ish) will cancel each other out. >=20 > You can filter or average wt + some phase to extract the phase. Or deriva= te "wt + some phase" then filter to get the filtered frequency. >=20 > So multiplying "y/x by x" would not make much sense in this case. No, multiplying by x doesn't make sense. Perhaps using a ROM for 1/x and a= multiplier would be better than a full divider.Article: 160696
On Thursday, October 18, 2018 at 9:22:47 AM UTC-6, gnuarm.del...@gmail.com = wrote: > I was wondering what the barriers are to new companies marketing FPGAs. = Some of the technological barriers are obvious. Designing a novel device i= s not so easy as the terrain is widely explored, so I expect any new player= would need to find a niche application of an unexplored technological feat= ure. =20 >=20 > Silicon Blue exploited a low power technology optimized for low cost devi= ces in mobile applications. They were successful enough to be bought by La= ttice and are still in production with the product line expanded considerab= ly. =20 >=20 > I believe Achronix started out with the idea of asynchronous logic. I'm = not clear if they continue to use that or not, but it is not apparent from = their web site. Their target is ultra fast clock speeds enabling FPGAs in = new market. I don't see then showing up on FPGA vendor lists so I assume t= hey are sill pretty low volume.=20 >=20 > Tabula was based on 3D technology, but they don't appear to have lasted. = I believe they were also claiming an ability to reconfigure logic in real = time which sounds like a very complex technology to master. Not sure what = market they were targeting.=20 >=20 > Other than the technologies, what other barriers do new FPGA companies fa= ce?=20 >=20 > Rick C. I've always wondered. So many companies have entered and then departed, le= aving the duopoly. I think it must be the problem of developing the tools.= As poor as they are, I think that might be the biggest impediment. Every= grand new idea seems to flounder in the face of what works. Most innovati= ons from Xilinx itself seem to flounder. Does anybody really use partial r= econfiguration, years and years after it was introduced? All the "high-lev= el" synthesis tools are either defunct or should be defunct.Article: 160697
On Thursday, October 18, 2018 at 9:22:47 AM UTC-6, gnuarm.del...@gmail.com = wrote: > I was wondering what the barriers are to new companies marketing FPGAs. = Some of the technological barriers are obvious. Designing a novel device i= s not so easy as the terrain is widely explored, so I expect any new player= would need to find a niche application of an unexplored technological feat= ure. =20 >=20 > Silicon Blue exploited a low power technology optimized for low cost devi= ces in mobile applications. They were successful enough to be bought by La= ttice and are still in production with the product line expanded considerab= ly. =20 >=20 > I believe Achronix started out with the idea of asynchronous logic. I'm = not clear if they continue to use that or not, but it is not apparent from = their web site. Their target is ultra fast clock speeds enabling FPGAs in = new market. I don't see then showing up on FPGA vendor lists so I assume t= hey are sill pretty low volume.=20 >=20 > Tabula was based on 3D technology, but they don't appear to have lasted. = I believe they were also claiming an ability to reconfigure logic in real = time which sounds like a very complex technology to master. Not sure what = market they were targeting.=20 >=20 > Other than the technologies, what other barriers do new FPGA companies fa= ce?=20 >=20 > Rick C. I'm not sure but I think Achronix dropped the whole asynchronous thing earl= y on, making their name a minsnomer.Article: 160698
On Thursday, October 18, 2018 at 2:41:32 PM UTC-4, Kevin Neilson wrote: > On Thursday, October 18, 2018 at 9:22:47 AM UTC-6, gnuarm.del...@gmail.co= m wrote: > > I was wondering what the barriers are to new companies marketing FPGAs.= Some of the technological barriers are obvious. Designing a novel device= is not so easy as the terrain is widely explored, so I expect any new play= er would need to find a niche application of an unexplored technological fe= ature. =20 > >=20 > > Silicon Blue exploited a low power technology optimized for low cost de= vices in mobile applications. They were successful enough to be bought by = Lattice and are still in production with the product line expanded consider= ably. =20 > >=20 > > I believe Achronix started out with the idea of asynchronous logic. I'= m not clear if they continue to use that or not, but it is not apparent fro= m their web site. Their target is ultra fast clock speeds enabling FPGAs i= n new market. I don't see then showing up on FPGA vendor lists so I assume= they are sill pretty low volume.=20 > >=20 > > Tabula was based on 3D technology, but they don't appear to have lasted= . I believe they were also claiming an ability to reconfigure logic in rea= l time which sounds like a very complex technology to master. Not sure wha= t market they were targeting.=20 > >=20 > > Other than the technologies, what other barriers do new FPGA companies = face?=20 > >=20 > > Rick C. >=20 > I've always wondered. So many companies have entered and then departed, = leaving the duopoly. I think it must be the problem of developing the tool= s. As poor as they are, I think that might be the biggest impediment. Eve= ry grand new idea seems to flounder in the face of what works. Most innova= tions from Xilinx itself seem to flounder. Does anybody really use partial= reconfiguration, years and years after it was introduced? All the "high-l= evel" synthesis tools are either defunct or should be defunct. I actually begged Xilinx for partial reconfiguration for many years. What = they eventually offered was so crappy that I never was able to use it... pl= us my need had gone by then. =20 No sure what you mean about "high level" synthesis. Are you talking about = something above HDL? Is this graphical?=20 Rick C.Article: 160699
On Thursday, October 18, 2018 at 2:42:46 PM UTC-4, Kevin Neilson wrote: > On Thursday, October 18, 2018 at 9:22:47 AM UTC-6, gnuarm.del...@gmail.co= m wrote: > > I was wondering what the barriers are to new companies marketing FPGAs.= Some of the technological barriers are obvious. Designing a novel device= is not so easy as the terrain is widely explored, so I expect any new play= er would need to find a niche application of an unexplored technological fe= ature. =20 > >=20 > > Silicon Blue exploited a low power technology optimized for low cost de= vices in mobile applications. They were successful enough to be bought by = Lattice and are still in production with the product line expanded consider= ably. =20 > >=20 > > I believe Achronix started out with the idea of asynchronous logic. I'= m not clear if they continue to use that or not, but it is not apparent fro= m their web site. Their target is ultra fast clock speeds enabling FPGAs i= n new market. I don't see then showing up on FPGA vendor lists so I assume= they are sill pretty low volume.=20 > >=20 > > Tabula was based on 3D technology, but they don't appear to have lasted= . I believe they were also claiming an ability to reconfigure logic in rea= l time which sounds like a very complex technology to master. Not sure wha= t market they were targeting.=20 > >=20 > > Other than the technologies, what other barriers do new FPGA companies = face?=20 > >=20 > > Rick C. >=20 > I'm not sure but I think Achronix dropped the whole asynchronous thing ea= rly on, making their name a minsnomer. I saw something that indicated they had a lot of push back from potential c= ustomers so that rather than letting them get access to it they somehow enc= apsulated it, but it's still there. The 1.5 GHz spec is still the same.=20 Rick C.
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