Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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

Custom Search

Messages from 160675

Article: 160675
Subject: Re: Strange thing, my FPGA HDMI output cannot work with cheap chinese HDMI Extender
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 22 Sep 2018 20:22:38 +0100 (BST)
Links: << >>  << T >>  << A >>
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.

Theo

Article: 160676
Subject: Need magic incantation to prevent synthesizer misoptimisation
From: Aleksandar Kuktin <ak@triklod.rs>
Date: Sun, 23 Sep 2018 01:03:30 +0000 (UTC)
Links: << >>  << T >>  << A >>
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
Subject: Re: Need magic incantation to prevent synthesizer misoptimisation
From: Gabor <nospam@nospam.com>
Date: Sun, 23 Sep 2018 09:17:50 -0400
Links: << >>  << T >>  << A >>
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: 160678
Subject: Re: Strange thing, my FPGA HDMI output cannot work with cheap chinese
From: abirov@gmail.com
Date: Tue, 25 Sep 2018 03:11:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thank 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
Subject: Re: Strange thing, my FPGA HDMI output cannot work with cheap chinese
From: abirov@gmail.com
Date: Tue, 25 Sep 2018 03:14:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: Strange thing, my FPGA HDMI output cannot work with cheap chinese HDMI Extender
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 25 Sep 2018 13:18:48 +0100 (BST)
Links: << >>  << T >>  << A >>
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


Theo

Article: 160681
Subject: Schematic FPGA Design on twitch
From: olli22221@web.de
Date: Thu, 27 Sep 2018 16:55:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 160682
Subject: Re: Strange thing, my FPGA HDMI output cannot work with cheap chinese
From: abirov@gmail.com
Date: Fri, 28 Sep 2018 02:50:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 HDMI

Article: 160683
Subject: Re: Schematic FPGA Design on twitch
From: Andy Bennet <andyb@andy.com>
Date: Fri, 28 Sep 2018 19:48:58 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: Schematic FPGA Design on twitch
From: o pere o <me@somewhere.net>
Date: Mon, 1 Oct 2018 08:52:32 +0200
Links: << >>  << T >>  << A >>
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 name

Article: 160685
Subject: Re: Need magic incantation to prevent synthesizer misoptimisation
From: Aleksandar Kuktin <ak@triklod.rs>
Date: Tue, 9 Oct 2018 17:44:02 +0000 (UTC)
Links: << >>  << T >>  << A >>
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
Subject: Re: What to do with an improved algorithm?
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Wed, 10 Oct 2018 18:52:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
> 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
Subject: Re: What to do with an improved algorithm?
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Thu, 11 Oct 2018 06:37:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: What to do with an improved algorithm?
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Thu, 11 Oct 2018 18:37:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
> 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
Subject: Re: What to do with an improved algorithm?
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Thu, 11 Oct 2018 21:42:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
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. =20


Article: 160690
Subject: Re: What to do with an improved algorithm?
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Fri, 12 Oct 2018 06:09:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: What to do with an improved algorithm?
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Tue, 16 Oct 2018 19:36:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
> 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
Subject: Re: What to do with an improved algorithm?
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Wed, 17 Oct 2018 08:26:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.=20

Article: 160693
Subject: FPGA Market Entry Barriers
From: gnuarm.deletethisbit@gmail.com
Date: Thu, 18 Oct 2018 08:22:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: FPGA Market Entry Barriers
From: lasselangwadtchristensen@gmail.com
Date: Thu, 18 Oct 2018 09:36:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 it

Article: 160695
Subject: Re: What to do with an improved algorithm?
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Thu, 18 Oct 2018 11:35:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: FPGA Market Entry Barriers
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Thu, 18 Oct 2018 11:41:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: FPGA Market Entry Barriers
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Thu, 18 Oct 2018 11:42:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: FPGA Market Entry Barriers
From: gnuarm.deletethisbit@gmail.com
Date: Thu, 18 Oct 2018 12:23:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Subject: Re: FPGA Market Entry Barriers
From: gnuarm.deletethisbit@gmail.com
Date: Thu, 18 Oct 2018 12:24:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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

Custom Search