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
Hello, I use Mike Fields vhdl code for hdmi processing. from Hamsterwork website. I want to Raspberry PI HDMI output connect to FPGA INPUT. I try 720p,1080p, progressive, interlaced and any kind of settings HDMI,DVI, component, RGB but result is nothing. I generate TMDS output from other fpga board and connect to HDMI input from other FPGA board and it works.. but Raspberry Pi don't want . Pls explain what problem ? DVI-D what Mike Fiel doing not a normal DVI-D ? Any help appreciated, I spend one week for this :( ..Article: 161551
I can connect to to fpga by I2C and get EDID ROM and parse it : pi@raspberrypi:~ $ edidparser asdf.dat Enabling fuzzy format match... Parsing asdf.dat... HDMI:EDID version 1.3, 1 extensions, screen size 16x9 cm HDMI:EDID features - videodef 0x80 !standby !suspend !active off; colour encoding:RGB444|YCbCr422; sRGB is not default colourspace; preferred format is native; does not support GTF HDMI:EDID found monitor range descriptor tag 0xfd HDMI:EDID monitor range offsets: V min=0, V max=0, H min=0, H max=0 HDMI:EDID monitor range: vertical is 24-75 Hz, horizontal is 26-81 kHz, max pixel clock is 230 MHz HDMI:EDID monitor range does not support GTF HDMI:EDID found monitor name descriptor tag 0xfc HDMI:EDID monitor name is SyncMaster HDMI:EDID found preferred CEA detail timing format: 1920x1080p @ 60 Hz (16) HDMI:EDID found CEA detail timing format: 1280x720p @ 50 Hz (19) HDMI:EDID established timing I/II bytes are BF EF 80 HDMI:EDID found DMT format: code 4, 640x480p @ 60 Hz in established timing I/II HDMI:EDID found DMT format: code 5, 640x480p @ 72 Hz in established timing I/II HDMI:EDID found DMT format: code 6, 640x480p @ 75 Hz in established timing I/II HDMI:EDID found DMT format: code 8, 800x600p @ 56 Hz in established timing I/II HDMI:EDID found DMT format: code 9, 800x600p @ 60 Hz in established timing I/II HDMI:EDID found DMT format: code 10, 800x600p @ 72 Hz in established timing I/II HDMI:EDID found DMT format: code 11, 800x600p @ 75 Hz in established timing I/II HDMI:EDID found DMT format: code 16, 1024x768p @ 60 Hz in established timing I/II HDMI:EDID found DMT format: code 17, 1024x768p @ 70 Hz in established timing I/II HDMI:EDID found DMT format: code 18, 1024x768p @ 75 Hz in established timing I/II HDMI:EDID found DMT format: code 36, 1280x1024p @ 75 Hz in established timing I/II HDMI:EDID standard timings block x 8: 0x714F 8100 8140 8180 9500 950F A940 B300 HDMI:EDID found DMT format: code 21, 1152x864p @ 75 Hz (4:3) in standard timing 0 HDMI:EDID found DMT format: code 28, 1280x800p @ 60 Hz (16:10) in standard timing 1 HDMI:EDID found DMT format: code 32, 1280x960p @ 60 Hz (4:3) in standard timing 2 HDMI:EDID found DMT format: code 35, 1280x1024p @ 60 Hz (5:4) in standard timing 3 HDMI:EDID found DMT format: code 47, 1440x900p @ 60 Hz (16:10) in standard timing 4 HDMI:EDID found DMT format: code 48, 1440x900p @ 75 Hz (16:10) in standard timing 5 HDMI:EDID found DMT format: code 51, 1600x1200p @ 60 Hz (4:3) in standard timing 6 HDMI:EDID found DMT format: code 58, 1680x1050p @ 60 Hz (16:10) in standard timing 7 HDMI:EDID parsing v3 CEA extension 0 HDMI:EDID monitor support - underscan IT formats:yes, basic audio:yes, yuv444:yes, yuv422:yes, #native DTD:1 HDMI:EDID found CEA detail timing format: 1920x1080i @ 50 Hz (20) HDMI:EDID found CEA detail timing format: 1920x1080i @ 60 Hz (5) HDMI:EDID found CEA detail timing format: 1280x720p @ 60 Hz (4) HDMI:EDID found CEA detail timing format: 720x576p @ 50 Hz (17) HDMI:EDID found CEA detail timing format: 720x480p @ 60 Hz (2) HDMI:EDID found CEA format: code 19, 1280x720p @ 50Hz (native) HDMI:EDID found CEA format: code 4, 1280x720p @ 60Hz HDMI:EDID found CEA format: code 5, 1920x1080i @ 60Hz HDMI:EDID found CEA format: code 20, 1920x1080i @ 50Hz HDMI:EDID found CEA format: code 3, 720x480p @ 60Hz HDMI:EDID found CEA format: code 18, 720x576p @ 50Hz HDMI:EDID found CEA format: code 16, 1920x1080p @ 60Hz HDMI:EDID found CEA format: code 31, 1920x1080p @ 50Hz HDMI:EDID found CEA format: code 32, 1920x1080p @ 24Hz HDMI:EDID found CEA format: code 33, 1920x1080p @ 25Hz HDMI:EDID found CEA format: code 34, 1920x1080p @ 30Hz HDMI:EDID found audio format 2 channels PCM, sample rate: 32|44|48 kHz, sample size: 16|20|24 bits HDMI:EDID found Video Capability DB length 2 HDMI:EDID video capability: CE:3 IT:3 PT:0 QS:0 HDMI:EDID found HDMI VSDB length 7 HDMI:EDID HDMI VSDB has physical address 1.0.0.0 HDMI:EDID HDMI VSDB supports AI:yes, dual link DVI:no HDMI:EDID HDMI VSDB deep colour support - 48-bit:no 36-bit:yes 30-bit:yes DC_yuv444:yes HDMI:EDID HDMI VSDB max TMDS clock 225 MHz HDMI:EDID HDMI VSDB has no latency information HDMI:EDID adding mandatory support for CEA (1) 640x480p @ 60Hz HDMI:EDID filtering formats with pixel clock unlimited MHz or h. blanking unlimited HDMI:EDID best score mode initialised to CEA (1) 640x480p @ 60 Hz with pixel clock 25 MHz (score 0) HDMI:EDID best score mode is now CEA (1) 640x480p @ 60 Hz with pixel clock 25 MHz (score 61864) HDMI:EDID best score mode is now CEA (2) 720x480p @ 60 Hz with pixel clock 27 MHz (score 2066472) HDMI:EDID CEA mode (3) 720x480p @ 60 Hz with pixel clock 27 MHz has a score of 66472 HDMI:EDID best score mode is now CEA (4) 1280x720p @ 60 Hz with pixel clock 74 MHz (score 3135592) HDMI:EDID DMT mode (4) 640x480p @ 60 Hz with pixel clock 25 MHz has a score of 18432 HDMI:EDID best score mode is now CEA (5) 1920x1080i @ 60 Hz with pixel clock 74 MHz (score 3773832) HDMI:EDID DMT mode (5) 640x480p @ 72 Hz with pixel clock 31 MHz has a score of 5529 HDMI:EDID DMT mode (6) 640x480p @ 75 Hz with pixel clock 31 MHz has a score of 5760 HDMI:EDID DMT mode (8) 800x600p @ 56 Hz with pixel clock 36 MHz has a score of 26880 HDMI:EDID DMT mode (9) 800x600p @ 60 Hz with pixel clock 40 MHz has a score of 28800 HDMI:EDID DMT mode (10) 800x600p @ 72 Hz with pixel clock 50 MHz has a score of 8640 HDMI:EDID DMT mode (11) 800x600p @ 75 Hz with pixel clock 49 MHz has a score of 9000 HDMI:EDID best score mode is now CEA (16) 1920x1080p @ 60 Hz with pixel clock 148 MHz (score 5398248) HDMI:EDID DMT mode (16) 1024x768p @ 60 Hz with pixel clock 65 MHz has a score of 47185 HDMI:EDID CEA mode (17) 720x576p @ 50 Hz with pixel clock 27 MHz has a score of 2566472 HDMI:EDID DMT mode (17) 1024x768p @ 70 Hz with pixel clock 75 MHz has a score of 13762 HDMI:EDID CEA mode (18) 720x576p @ 50 Hz with pixel clock 27 MHz has a score of 66472 HDMI:EDID DMT mode (18) 1024x768p @ 75 Hz with pixel clock 78 MHz has a score of 14745 HDMI:EDID CEA mode (19) 1280x720p @ 50 Hz with pixel clock 74 MHz has a score of 4663240 HDMI:EDID CEA mode (20) 1920x1080i @ 50 Hz with pixel clock 74 MHz has a score of 4232360 HDMI:EDID DMT mode (21) 1152x864p @ 75 Hz with pixel clock 108 MHz has a score of 43662 HDMI:EDID DMT mode (28) 1280x800p @ 60 Hz with pixel clock 83 MHz has a score of 86440 HDMI:EDID CEA mode (31) 1920x1080p @ 50 Hz with pixel clock 148 MHz has a score of 232360 HDMI:EDID CEA mode (32) 1920x1080p @ 24 Hz with pixel clock 74 MHz has a score of 124532 HDMI:EDID DMT mode (32) 1280x960p @ 60 Hz with pixel clock 108 MHz has a score of 98728 HDMI:EDID CEA mode (33) 1920x1080p @ 25 Hz with pixel clock 74 MHz has a score of 128680 HDMI:EDID CEA mode (34) 1920x1080p @ 30 Hz with pixel clock 74 MHz has a score of 149416 HDMI:EDID DMT mode (35) 1280x1024p @ 60 Hz with pixel clock 108 MHz has a score of 103643 HDMI:EDID DMT mode (36) 1280x1024p @ 75 Hz with pixel clock 135 MHz has a score of 24576 HDMI:EDID DMT mode (47) 1440x900p @ 60 Hz with pixel clock 106 MHz has a score of 102760 HDMI:EDID DMT mode (48) 1440x900p @ 75 Hz with pixel clock 136 MHz has a score of 49300 HDMI:EDID DMT mode (51) 1600x1200p @ 60 Hz with pixel clock 162 MHz has a score of 140200 HDMI:EDID DMT mode (58) 1680x1050p @ 60 Hz with pixel clock 146 MHz has a score of 130840 HDMI0:EDID preferred mode remained as CEA (16) 1920x1080p @ 60 Hz with pixel clock 148 MHz HDMI:EDID has HDMI support and audio support edidparser exited with code 0 HERE IS MY config.txt # uncomment if you get no picture on HDMI for a default "safe" mode #hdmi_safe=1 # uncomment to force a console size. By default it will be display's size minus # overscan. #framebuffer_width=1280 #framebuffer_height=720 # uncomment if hdmi display is not detected and composite is being output hdmi_force_hotplug=1 # uncomment to force a specific HDMI mode (this will force VGA) hdmi_group=1 hdmi_mode=16 # uncomment to force a HDMI mode rather than DVI. This can make audio work in # DMT (computer monitor) modes hdmi_drive=1 # uncomment to increase signal to HDMI, if you have interference, blanking, or # no display config_hdmi_boost=4 # uncomment for composite PAL 0-NTSC,1-JapanNTSC,2-PAL,3 Brasilian PAL #sdtv_mode=0 #uncomment to overclock the arm. 700 MHz is the default. arm_freq=1000 # Uncomment some or all of these to enable the optional hardware interfaces dtparam=i2c_arm=on #dtparam=i2s=on #dtparam=spi=on # Uncomment this to enable the lirc-rpi module #dtoverlay=lirc-rpi # Additional overlays and parameters are documented /boot/overlays/README # Enable audio (loads snd_bcm2835) dtparam=audio=on core_freq=500 sdram_freq=500 over_voltage=2 start_x=1 gpu_mem=128 ########################## hdmi_edid_file=1 hdmi_ignore_edid=0xa5000080Article: 161552
HERE is link to fpga project. http://hamsterworks.co.nz/mediawiki/index.php/HDMI_ProcessingArticle: 161553
On Friday, November 29, 2019 at 2:51:51 AM UTC-5, Brane2 wrote: > I'm talking about these guys: >=20 > https://www.efinixinc.com >=20 > Their Trion program seems interesting: >=20 > - it stretches from area that is occupied by Lattice's MachXO3 on the low= end and ECP5 on hight end > - no onboard FLASH.Just OTP on few small models and nothing on high end > - universal tile that can do routing as well as LUT/MEM/logic > - 5 bit BLOCK RAM instead of traditional 9-bit > - additional simpplifications on the process end claim 4x chip price redu= ction ( only 7 metalisation layers instead of 14 etc) >=20 > Trion on first impression looks nice, but: >=20 > - a bit slower than ECP5 > - based on digikey prices, not cheaper than EPC5, or even pricier at some= points >=20 > has anyone used them and has some data to share on the matter ? They do seem to be a bit of "me too" in the FPGA arena. Not only are their= parts about the same as others already in the field and about the same pri= cing, they are using all the same BGA type of packaging and the same sort o= f hard IP. I see the smallest part in the family doesn't have any LVDS I/O= . =20 The main complaint I have with them is the near total use of BGA packages. = My needs are typically for something like a QFN88 or a QFP100. The QFP144= won't even fit on my board, lol. =20 The T8F81C2 in the BGA81 package is certainly affordable at $5.50. I just = wish it had something like a CM0/CM3 processor on the die. I'm going to ke= ep watching Gowin and AGM.=20 --=20 Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209Article: 161554
On Friday, November 29, 2019 at 3:00:20 AM UTC-5, Brane2 wrote: > One more question: > > At least on the first glance, I've got the impression that Trion is not as fast as ECP5. Is this about right ? > If so, why do you think this is - power optimisation or perhaps consequence of unified routing/LUT/MEM approach ? What are you looking at regarding the speed? It is hard to find comparable speed data for FPGAs. I expect you would need to P&R a test design to get any meaningful data. -- Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209Article: 161555
On Friday, November 29, 2019 at 2:56:19 AM UTC-5, Brane2 wrote: > I've noticed that literally over night ordinary ( non-SERDES, non-automot= ive) members of ECP5 family is gone on Lattice's pages. >=20 > Questions: >=20 > 1. Is there process advancement comming ( 40nm ->28 nm or similar) > 2. Are we to see iCE50, MachXO4, ECP6 shortly ? > 3. How much of this is caused by process advancement (like 28 nm becoming= more cost-effective than 40nm for the purpose etc) ? > 4. How much of this is caused by IoT and AI expansion ? > 5. HOw much of this is caued by new names and offers ( Effinix, new Chine= se names etc) ? I would ask what you have been smoking!??? I see parts that are not SERDES= and not automotive. They are in the same table as the rest of the ECP5 no= n-automotive parts, on the right. I guess they are easy to overlook on the= right side of the table. =20 Not sure what an ICE50 would be other than a step backwards. The original = devices were the ICE65 made on a 65 nm process which was very quickly repla= ced with smaller, but more static power hungry ICE40 parts on a 40 nm proce= ss. So ICE50 would be reversing course. Maybe ICE28, but who knows? =20 --=20 Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209Article: 161556
On 11/29/19 10:06 AM, Rick C wrote: > On Friday, November 29, 2019 at 2:51:51 AM UTC-5, Brane2 wrote: >> I'm talking about these guys: >> >> https://www.efinixinc.com >> >> Their Trion program seems interesting: >> >> - it stretches from area that is occupied by Lattice's MachXO3 on the low end and ECP5 on hight end >> - no onboard FLASH.Just OTP on few small models and nothing on high end >> - universal tile that can do routing as well as LUT/MEM/logic >> - 5 bit BLOCK RAM instead of traditional 9-bit >> - additional simpplifications on the process end claim 4x chip price reduction ( only 7 metalisation layers instead of 14 etc) >> >> Trion on first impression looks nice, but: >> >> - a bit slower than ECP5 >> - based on digikey prices, not cheaper than EPC5, or even pricier at some points >> >> has anyone used them and has some data to share on the matter ? > > They do seem to be a bit of "me too" in the FPGA arena. Not only are their parts about the same as others already in the field and about the same pricing, they are using all the same BGA type of packaging and the same sort of hard IP. I see the smallest part in the family doesn't have any LVDS I/O. > > The main complaint I have with them is the near total use of BGA packages. My needs are typically for something like a QFN88 or a QFP100. The QFP144 won't even fit on my board, lol. > > The T8F81C2 in the BGA81 package is certainly affordable at $5.50. I just wish it had something like a CM0/CM3 processor on the die. I'm going to keep watching Gowin and AGM. > I think one reason for the predominance of BGA packages is that they are a lot smaller than non-BGA packages, even with a lot less pins. Yes, there are board cost/assembly issues with BGAs, but my guess is that there isn't enough demand at the very small end to make it worth the tooling cost to make them.Article: 161557
On Thursday, November 28, 2019 at 4:33:59 PM UTC-5, Weng Tianxiang wrote: > On Thursday, November 28, 2019 at 12:44:48 PM UTC-8, KJ wrote: > > Please read my diagrams carefully in my patent and you are familiar with none of what I asked you to check my application for specification and diagrams 9 years ago. I referenced and commented on the unsubstantiated claim you made in the posting you made in this newsgroup. You have not provided any evidence backing your statement. > > I remember you were talking about some jumping signal generations last time and I didn't see any point of your argument. OK, but that speaks to your abilities. > > Let HT-Lab or Rick as arbitrator to determine whether your standpoint is meaningless or not. Last time Rick was on my side. HAHAHA, we're choosing teams now??? > > Actually this patent, US 10482208, has nothing to do with how to generate jumping signals for a state machine!!! Who care what the patent has nothing to do about? Kevin JenningsArticle: 161558
When ATPG errors
suppose an ATPG errors with slight probability p
p->0
now suppose it is used to calculate untestability of a fault.
Let T be 1 if fault is testable, let T be 0 if fault is untestable.
Now, suppose we use an errorneous ATPG be T OR A, where A = and(x1,x2......x_n)
where n->infinity.
the average <T OR A> for an untestable fault if n->infinity = <T> = 0 in RTG
T = T OR A for exactly for every case except 1 case, for an untestable fault.
Now, T OR A can be solved by deterministic ATPG, T OR A = 1.
<T OR A> = <T> = 0 , is untestable by RTG ATPG. <T OR A> = 0 , therefore has 0 solutions.
Proof
<T OR A> = 1/2^n
no. of solutions = <T OR A> * 2^n = ( 1/2^n )*2^n
= lim episoln1,2->0 n->infinity (1/2^n -episoln1+episoln2)*2^n
as n->infinity select episoln1=1/2^n
= (0 +episoln2)*2^n
Select episoln2=0, such that episoln2*2^n =0
= 0
no. of solutions = 0;
T OR A has 1 solution by deterministic ATPG.
Therefore
solutions= 0 = 1
Suppose T is the output T + 0 = T + solutions = T + 1, if T is 0 = 1, if T- 0 = = T - solutions = T - 1 if T is 1 = 0
untestable is testable, testable is untestable!
Such effects may be heuristically observable.
ATPG will remain unsolved
Suppose a cripple found a solution and
says it is solved, since a cripple found it , it is not solved.
Article: 161559On Friday, November 29, 2019 at 6:51:08 PM UTC-5, const...@gmail.com wrote: > When ATPG errors > > suppose an ATPG errors with slight probability p > p->0 > > now suppose it is used to calculate untestability of a fault. > > Let T be 1 if fault is testable, let T be 0 if fault is untestable. > > > Now, suppose we use an errorneous ATPG be T OR A, where A = and(x1,x2......x_n) > > where n->infinity. > > > the average <T OR A> for an untestable fault if n->infinity = <T> = 0 in RTG > > T = T OR A for exactly for every case except 1 case, for an untestable fault. > > > Now, T OR A can be solved by deterministic ATPG, T OR A = 1. > > > <T OR A> = <T> = 0 , is untestable by RTG ATPG. <T OR A> = 0 , therefore has 0 solutions. > > Proof > > <T OR A> = 1/2^n > > no. of solutions = <T OR A> * 2^n = ( 1/2^n )*2^n > = lim episoln1,2->0 n->infinity (1/2^n -episoln1+episoln2)*2^n > as n->infinity select episoln1=1/2^n > = (0 +episoln2)*2^n > Select episoln2=0, such that episoln2*2^n =0 > = 0 > no. of solutions = 0; > > T OR A has 1 solution by deterministic ATPG. > > Therefore > solutions= 0 = 1 > > Suppose T is the output T + 0 = T + solutions = T + 1, if T is 0 = 1, if T- 0 = = T - solutions = T - 1 if T is 1 = 0 > > untestable is testable, testable is untestable! > Such effects may be heuristically observable. > > ATPG will remain unsolved > > Suppose a cripple found a solution and > says it is solved, since a cripple found it , it is not solved. -sureshArticle: 161560
On Friday, November 29, 2019 at 12:49:13 PM UTC-5, Richard Damon wrote: > On 11/29/19 10:06 AM, Rick C wrote: > > On Friday, November 29, 2019 at 2:51:51 AM UTC-5, Brane2 wrote: > >> I'm talking about these guys: > >> > >> https://www.efinixinc.com > >> > >> Their Trion program seems interesting: > >> > >> - it stretches from area that is occupied by Lattice's MachXO3 on the = low end and ECP5 on hight end > >> - no onboard FLASH.Just OTP on few small models and nothing on high en= d > >> - universal tile that can do routing as well as LUT/MEM/logic > >> - 5 bit BLOCK RAM instead of traditional 9-bit > >> - additional simpplifications on the process end claim 4x chip price r= eduction ( only 7 metalisation layers instead of 14 etc) > >> > >> Trion on first impression looks nice, but: > >> > >> - a bit slower than ECP5 > >> - based on digikey prices, not cheaper than EPC5, or even pricier at s= ome points > >> > >> has anyone used them and has some data to share on the matter ? > >=20 > > They do seem to be a bit of "me too" in the FPGA arena. Not only are t= heir parts about the same as others already in the field and about the same= pricing, they are using all the same BGA type of packaging and the same so= rt of hard IP. I see the smallest part in the family doesn't have any LVDS= I/O. =20 > >=20 > > The main complaint I have with them is the near total use of BGA packag= es. My needs are typically for something like a QFN88 or a QFP100. The QF= P144 won't even fit on my board, lol. =20 > >=20 > > The T8F81C2 in the BGA81 package is certainly affordable at $5.50. I j= ust wish it had something like a CM0/CM3 processor on the die. I'm going t= o keep watching Gowin and AGM.=20 > >=20 >=20 > I think one reason for the predominance of BGA packages is that they are > a lot smaller than non-BGA packages, even with a lot less pins. Yes, > there are board cost/assembly issues with BGAs, but my guess is that > there isn't enough demand at the very small end to make it worth the > tooling cost to make them. Yes, I'm sure of that, but there are companies selling FPGAs in 100QFP. No= w there are a couple of start ups using that package as well as the 88QFN. = If you aren't building cell phones, these are alternatives providing a low= er system cost not to mention ease of inspection and rework.=20 In particular AGM has 6 kLUT and a 250 MHz CM3 in a 100QFP (if you can buy = it) and Gowin has a 4 kLUT part in both a 100QFP and the 88QFN for under $3= .40 (a part with a CM3 processor will be out in Q1). =20 --=20 Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209Article: 161561
On Friday, November 29, 2019 at 2:03:41 PM UTC-8, KJ wrote: > On Thursday, November 28, 2019 at 4:33:59 PM UTC-5, Weng Tianxiang wrote: > > On Thursday, November 28, 2019 at 12:44:48 PM UTC-8, KJ wrote: > >=20 > > Please read my diagrams carefully in my patent and you are familiar wit= h none of what I asked you to check my application for specification and di= agrams 9 years ago. > I referenced and commented on the unsubstantiated claim you made in the p= osting you made in this newsgroup. You have not provided any evidence back= ing your statement. >=20 > >=20 > > I remember you were talking about some jumping signal generations last = time and I didn't see any point of your argument.=20 > OK, but that speaks to your abilities. >=20 > >=20 > > Let HT-Lab or Rick as arbitrator to determine whether your standpoint i= s meaningless or not. Last time Rick was on my side. >=20 > HAHAHA, we're choosing teams now??? >=20 > >=20 > > Actually this patent, US 10482208, has nothing to do with how to genera= te jumping signals for a state machine!!! > Who care what the patent has nothing to do about? >=20 > Kevin Jennings KJ, On one side you said:=20 "I referenced and commented on the unsubstantiated claim you made in the po= sting you made in this newsgroup."=20 On other side you said: "Who care what the patent has nothing to do about?" Here are the facts: 1. It became patent US 10482208 since 11/19/2019. 2. If you can pinpoint any unsubstantiated claim from the official US pate= nt, what you make may invalidate the patent.=20 3. I welcome your action and have no objection against it, because I believ= e the state machine's new coding method certainly will be accepted into HDL= SOMEDAY, because it generates no burden for coding state machines and fina= lly perfects the work made by a lot of papers one of which has 224 cites,= =20 http://www.scarpaz.com/2100-papers/Low%20Power/00503933.pdf,=20 and every code designer will benefit on the new coding method. Last time Rick and you were arguing against each other on your pointless po= ints and I firmly stand with Rick, but I did not participate your argument,= not because you are an expert and comments are valuable, but because your = point is no sense and pointless in any way and I don't want to spend any ti= me on your pointless points.=20 KJ, please be BRAVE to pinpoint WHICH PAGE, WHICH LINES =E5=93=A6=E4=BA=BAW= HICH FIGURES have any type of LOGIC and SIGNIFICANT errors. If you do this I will response to your points immediately and let Rick and = HT-Lab determine if your claim is pointless or not, otherwise I will ignore= all your later posts on this subject.=20 9 (nine) years ago I asked you to help me to check the application text for= grammar errors and I thank you for your help with paying.=20 Now it became a patent with all brand new figures and specifications you ha= ve never seen it before publication, and all figures, specification, claims= for the patent were made by myself. WengArticle: 161562
I checked with Oscilloscope on hdmi port on RPI3b, difference between working monitor and fpga board,everything except TMDS channels are same, only TMDS channels are down.Article: 161563
Dne petek, 29. november 2019 15.21.42 UTC je oseba Rick C napisala: =20 > I would ask what you have been smoking!??? I see parts that are not SERD= ES and not automotive. They are in the same table as the rest of the ECP5 = non-automotive parts, on the right. I guess they are easy to overlook on t= he right side of the table. =20 It looks like they've been arearangig those pages. Previous version had eac= h family version in separate table, with its own enclosure combinations. I've seen new version without updated headers, which was fixed shortly afte= r... =20 > Not sure what an ICE50 would be other than a step backwards. The origina= l devices were the ICE65 made on a 65 nm process which was very quickly rep= laced with smaller, but more static power hungry ICE40 parts on a 40 nm pro= cess. So ICE50 would be reversing course. Maybe ICE28, but who knows?=20 I've meant to say next-gen. Didn't know that "40" signifies geometry size.= =20 But while at it, with densities that low, geometry shrink is not always opt= imal, so who knows, they might do that or stay on 4onm buit use fundamental= ly different process etc.Article: 161564
On 30/11/2019 03:56, Weng Tianxiang wrote: > On Friday, November 29, 2019 at 2:03:41 PM UTC-8, KJ wrote: >> On Thursday, November 28, 2019 at 4:33:59 PM UTC-5, Weng Tianxiang wrote: >>> On Thursday, November 28, 2019 at 12:44:48 PM UTC-8, KJ wrote: >>> >>> Please read my diagrams carefully in my patent and you are familiar with none of what I asked you to check my application for specification and diagrams 9 years ago. >> I referenced and commented on the unsubstantiated claim you made in the posting you made in this newsgroup. You have not provided any evidence backing your statement. I do not see how your re-arrangment of state machines saves power if this is the fundamental goal. In FPGA design it is a definate no-no to gate the clock signal into a F/F, or indeed manufacture a clock signal from a logic expression which will produce difficult to predict setup and hold times as well as glitches. The power in a F/F is predominantly driven by the change of state of the flip flop. You should only 'gate' the clock into a F/F by using its enable control line. The F/F remains continuously clocked, but the input of the flip flop is controlled by the enable to either be the output of the flip flop or new data. This then gives predicatable setup and hold times and a glitch free operation - assuming the enables are synchronous, which is basic design practise. ABArticle: 161565
>=20 > I do not see how your re-arrangment of state machines saves power if=20 > this is the fundamental goal. > In FPGA design it is a definate no-no to gate the clock signal into a=20 > F/F, or indeed manufacture a clock signal from a logic expression which= =20 > will produce difficult to predict setup and hold times as well as glitche= s. > The power in a F/F is predominantly driven by the change of state of the= =20 > flip flop. > You should only 'gate' the clock into a F/F by using its enable control= =20 > line. The F/F remains continuously clocked, but the input of the flip=20 > flop is controlled by the enable to either be the output of the flip=20 > flop or new data. > This then gives predicatable setup and hold times and a glitch free=20 > operation - assuming the enables are synchronous, which is basic design= =20 > practise. >=20 > AB AB, Good, a technical and basic question!!! A F/F saves power if it does not receive clock pulse when its states do not= change. In my design a F/F input pin always has '0' input if it does not change sta= tes and I don't know if it saves power. Please refer to this paper suggested by dlhe in his earlier post and my pat= ent does not have to further explain it. I read the paper only after dlhe s= uggested and found the paper does many experiments to confirm how it saves = power. The paper has a paragraph "4. Experiment Results" which uses their experime= nts to show it saves power. Weng http://apachepersonal.miun.se/~benoel/download/papers/Asynch_control_FSM.pd= f Asynchronous control of low-power gated-clock finite-state-machines : ICECS'99. Proceedings of ICECS '99. 6th IEEE International Conference on = Electronics, Circuits and Systems An efficient approach to reduce power consumption in a synchronous Finite-S= tate Machine (FSM) is to de-compose it, according to a partitioning algorit= hm, to a number of sub-FSMs that interact through some communication signal= s. Only one sub-FSM is clocked at a time and low power operation is obtaine= d by only clocking the active sub-FSM. In this paper we introduce a new asy= nchronous communication control for the interacting sub-FSMs, which reduces= the total capacitance switched by the system clock. Experimental results s= how that this leads to significant power savings when the FSM is partitione= d into many sub-FSMs.Article: 161566
On Saturday, November 30, 2019 at 2:26:31 AM UTC-5, Brane2 wrote: > Dne petek, 29. november 2019 15.21.42 UTC je oseba Rick C napisala: > =20 > > I would ask what you have been smoking!??? I see parts that are not SE= RDES and not automotive. They are in the same table as the rest of the ECP= 5 non-automotive parts, on the right. I guess they are easy to overlook on= the right side of the table. =20 >=20 > It looks like they've been arearangig those pages. Previous version had e= ach family version in separate table, with its own enclosure combinations. > I've seen new version without updated headers, which was fixed shortly af= ter... >=20 > =20 > > Not sure what an ICE50 would be other than a step backwards. The origi= nal devices were the ICE65 made on a 65 nm process which was very quickly r= eplaced with smaller, but more static power hungry ICE40 parts on a 40 nm p= rocess. So ICE50 would be reversing course. Maybe ICE28, but who knows?= =20 >=20 > I've meant to say next-gen. Didn't know that "40" signifies geometry size= .=20 > But while at it, with densities that low, geometry shrink is not always o= ptimal, so who knows, they might do that or stay on 4onm buit use fundament= ally different process etc. In the old days a shrink would be done on a design that reduced dimensions = in the X and Y direction without changing the Z dimension features. This w= as less work than a full scaling but didn't offer the full benefits (I migh= t have the terms switched). I don't think they do that anymore as the deta= ils involved are more complex and since these processes are not at all on t= he cutting edge, but rather are well established "mature" processes at this= point and so it is unlikely they would do anything other than move from on= e process to the next. =20 I think there are issues with combining Flash with logic processes and that= typically lags the state of the art by several generations. The ICE parts= don't have flash, they have RAM and one time programmable PROM. =20 I believe the ICE parts are not about speed, rather cost, so presently the = 40 nm process is "good enough". We will see what the recent competition wi= ll do for that. =20 --=20 Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209Article: 161567
On 11/30/19 3:24 AM, Andy Bennet wrote: > On 30/11/2019 03:56, Weng Tianxiang wrote: >> On Friday, November 29, 2019 at 2:03:41 PM UTC-8, KJ wrote: >>> On Thursday, November 28, 2019 at 4:33:59 PM UTC-5, Weng Tianxiang >>> wrote: >>>> On Thursday, November 28, 2019 at 12:44:48 PM UTC-8, KJ wrote: >>>> >>>> Please read my diagrams carefully in my patent and you are familiar >>>> with none of what I asked you to check my application for >>>> specification and diagrams 9 years ago. >>> I referenced and commented on the unsubstantiated claim you made in >>> the posting you made in this newsgroup. You have not provided any >>> evidence backing your statement. > > I do not see how your re-arrangment of state machines saves power if > this is the fundamental goal. > In FPGA design it is a definate no-no to gate the clock signal into a > F/F, or indeed manufacture a clock signal from a logic expression which > will produce difficult to predict setup and hold times as well as glitches. > The power in a F/F is predominantly driven by the change of state of the > flip flop. > You should only 'gate' the clock into a F/F by using its enable control > line. The F/F remains continuously clocked, but the input of the flip > flop is controlled by the enable to either be the output of the flip > flop or new data. > This then gives predicatable setup and hold times and a glitch free > operation - assuming the enables are synchronous, which is basic design > practise. > > AB There are FPGAs which provide a 'gated clock' but they do the gating at the row or region driver level, as that is where you get better power savings (driving the clock tree is a significant use of power, while gating at the flip-flop level saves virtually nothing, if it doesn't cost you due to the extra logic, if it needs a LUT to gate, you have lost) These gated clock drivers tend to have de-glitching logic on them that makes them safe to use (gate signal low keeps the output clock from going high but doesn't force a high output low). This says that you can save power if you know a whole section won't be changing for awhile, but unlikely helps on a small state machine that occasionally doesn't change, as the power in the change prediction logic may cost more than the savings. Also, since these clock drivers are a limited critical resource, you likely don't have enough to use it fine grain.Article: 161568
On Saturday, 11/30/2019 8:54 AM, Rick C wrote: > On Saturday, November 30, 2019 at 2:26:31 AM UTC-5, Brane2 wrote: >> Dne petek, 29. november 2019 15.21.42 UTC je oseba Rick C napisala: >> >>> I would ask what you have been smoking!??? I see parts that are not SERDES and not automotive. They are in the same table as the rest of the ECP5 non-automotive parts, on the right. I guess they are easy to overlook on the right side of the table. >> >> It looks like they've been arearangig those pages. Previous version had each family version in separate table, with its own enclosure combinations. >> I've seen new version without updated headers, which was fixed shortly after... >> >> >>> Not sure what an ICE50 would be other than a step backwards. The original devices were the ICE65 made on a 65 nm process which was very quickly replaced with smaller, but more static power hungry ICE40 parts on a 40 nm process. So ICE50 would be reversing course. Maybe ICE28, but who knows? >> >> I've meant to say next-gen. Didn't know that "40" signifies geometry size. >> But while at it, with densities that low, geometry shrink is not always optimal, so who knows, they might do that or stay on 4onm buit use fundamentally different process etc. > > In the old days a shrink would be done on a design that reduced dimensions in the X and Y direction without changing the Z dimension features. This was less work than a full scaling but didn't offer the full benefits (I might have the terms switched). I don't think they do that anymore as the details involved are more complex and since these processes are not at all on the cutting edge, but rather are well established "mature" processes at this point and so it is unlikely they would do anything other than move from one process to the next. > > I think there are issues with combining Flash with logic processes and that typically lags the state of the art by several generations. The ICE parts don't have flash, they have RAM and one time programmable PROM. > > I believe the ICE parts are not about speed, rather cost, so presently the 40 nm process is "good enough". We will see what the recent competition will do for that. > ICE parts were all about low power, especially ultra-low standby power. Going to smaller nodes can be detrimental to standby power due to increased leakage. Trying to keep the standby power low when reducing the geometry can lead to speeds that are almost the same as the larger geometry, so unless you needed to pack more into the same die size you don't really buy anything. I also don't think that the ICE line is central to Lattice's future business model. ICE5 Ultra is likely the end of the line for it. (probably have to eat my words :-) -- GaborArticle: 161569
On Saturday, November 30, 2019 at 9:16:40 AM UTC-5, Richard Damon wrote: > On 11/30/19 3:24 AM, Andy Bennet wrote: > > On 30/11/2019 03:56, Weng Tianxiang wrote: > >> On Friday, November 29, 2019 at 2:03:41 PM UTC-8, KJ wrote: > >>> On Thursday, November 28, 2019 at 4:33:59 PM UTC-5, Weng Tianxiang > >>> wrote: > >>>> On Thursday, November 28, 2019 at 12:44:48 PM UTC-8, KJ wrote: > >>>> > >>>> Please read my diagrams carefully in my patent and you are familiar > >>>> with none of what I asked you to check my application for > >>>> specification and diagrams 9 years ago. > >>> I referenced and commented on the unsubstantiated claim you made in > >>> the posting you made in this newsgroup.=C2=A0 You have not provided a= ny > >>> evidence backing your statement. > >=20 > > I do not see how your re-arrangment of state machines saves power if > > this is the fundamental goal. > > In FPGA design it is a definate no-no to gate the clock signal into a > > F/F, or indeed manufacture a clock signal from a logic expression which > > will produce difficult to predict setup and hold times as well as glitc= hes. > > The power in a F/F is predominantly driven by the change of state of th= e > > flip flop. > > You should only 'gate' the clock into a F/F by using its enable control > > line. The F/F remains continuously clocked, but the input of the flip > > flop is controlled by the enable to either be the output of the flip > > flop or new data. > > This then gives predicatable setup and hold times and a glitch free > > operation - assuming the enables are synchronous, which is basic design > > practise. > >=20 > > AB >=20 > There are FPGAs which provide a 'gated clock' but they do the gating at > the row or region driver level, as that is where you get better power > savings (driving the clock tree is a significant use of power, while > gating at the flip-flop level saves virtually nothing, if it doesn't > cost you due to the extra logic, if it needs a LUT to gate, you have lost= ) >=20 > These gated clock drivers tend to have de-glitching logic on them that > makes them safe to use (gate signal low keeps the output clock from > going high but doesn't force a high output low). This says that you can > save power if you know a whole section won't be changing for awhile, but > unlikely helps on a small state machine that occasionally doesn't > change, as the power in the change prediction logic may cost more than > the savings. Also, since these clock drivers are a limited critical > resource, you likely don't have enough to use it fine grain. Who makes these FPGAs? Are these in the typical clock generators most FPGA= s have only a handful of? That's still better than no clock gating.=20 --=20 Rick C. +- Get 1,000 miles of free Supercharging +- Tesla referral code - https://ts.la/richard11209Article: 161570
On Saturday, November 30, 2019 at 9:32:11 AM UTC-5, Gabor wrote: > On Saturday, 11/30/2019 8:54 AM, Rick C wrote: > > On Saturday, November 30, 2019 at 2:26:31 AM UTC-5, Brane2 wrote: > >> Dne petek, 29. november 2019 15.21.42 UTC je oseba Rick C napisala: > >> =20 > >>> I would ask what you have been smoking!??? I see parts that are not = SERDES and not automotive. They are in the same table as the rest of the E= CP5 non-automotive parts, on the right. I guess they are easy to overlook = on the right side of the table. > >> > >> It looks like they've been arearangig those pages. Previous version ha= d each family version in separate table, with its own enclosure combination= s. > >> I've seen new version without updated headers, which was fixed shortly= after... > >> > >> =20 > >>> Not sure what an ICE50 would be other than a step backwards. The ori= ginal devices were the ICE65 made on a 65 nm process which was very quickly= replaced with smaller, but more static power hungry ICE40 parts on a 40 nm= process. So ICE50 would be reversing course. Maybe ICE28, but who knows? > >> > >> I've meant to say next-gen. Didn't know that "40" signifies geometry s= ize. > >> But while at it, with densities that low, geometry shrink is not alway= s optimal, so who knows, they might do that or stay on 4onm buit use fundam= entally different process etc. > >=20 > > In the old days a shrink would be done on a design that reduced dimensi= ons in the X and Y direction without changing the Z dimension features. Th= is was less work than a full scaling but didn't offer the full benefits (I = might have the terms switched). I don't think they do that anymore as the = details involved are more complex and since these processes are not at all = on the cutting edge, but rather are well established "mature" processes at = this point and so it is unlikely they would do anything other than move fro= m one process to the next. > >=20 > > I think there are issues with combining Flash with logic processes and = that typically lags the state of the art by several generations. The ICE p= arts don't have flash, they have RAM and one time programmable PROM. > >=20 > > I believe the ICE parts are not about speed, rather cost, so presently = the 40 nm process is "good enough". We will see what the recent competitio= n will do for that. > >=20 >=20 > ICE parts were all about low power, especially ultra-low standby power. > Going to smaller nodes can be detrimental to standby power due to > increased leakage. Trying to keep the standby power low when reducing > the geometry can lead to speeds that are almost the same as the larger > geometry, so unless you needed to pack more into the same die size you > don't really buy anything. I also don't think that the ICE line is > central to Lattice's future business model. ICE5 Ultra is likely the > end of the line for it. (probably have to eat my words :-) I believe they can optimize a given geometry for power vs. speed, but I don= 't know for sure. The original 65 nm ICE65 chips had static power specs of= low double digit uA. The ICE40 products are 100 uA for most I believe. T= here are some very small devices ~400 LUTs that are lower and one of the ne= w Ultra families get below 50 uA I believe. Still, they took a hit on this= moving to 40 nm. With all the focus on low power in computing, do you thi= nk they can't move down a process node or two and retain the current static= levels?=20 --=20 Rick C. -- Get 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209Article: 161571
On 11/30/19 9:55 AM, Rick C wrote: > On Saturday, November 30, 2019 at 9:16:40 AM UTC-5, Richard Damon wrote: >> >> There are FPGAs which provide a 'gated clock' but they do the gating at >> the row or region driver level, as that is where you get better power >> savings (driving the clock tree is a significant use of power, while >> gating at the flip-flop level saves virtually nothing, if it doesn't >> cost you due to the extra logic, if it needs a LUT to gate, you have lost) >> >> These gated clock drivers tend to have de-glitching logic on them that >> makes them safe to use (gate signal low keeps the output clock from >> going high but doesn't force a high output low). This says that you can >> save power if you know a whole section won't be changing for awhile, but >> unlikely helps on a small state machine that occasionally doesn't >> change, as the power in the change prediction logic may cost more than >> the savings. Also, since these clock drivers are a limited critical >> resource, you likely don't have enough to use it fine grain. > > Who makes these FPGAs? Are these in the typical clock generators most FPGAs have only a handful of? That's still better than no clock gating. > Microsemi, now part of Microchip. The gating is part of the regional clock driving tree, so is somewhat limited, but not as limited as the master clock generators (which also have gating).Article: 161572
On Saturday, November 30, 2019 at 11:33:45 AM UTC-5, Richard Damon wrote: > On 11/30/19 9:55 AM, Rick C wrote: > > On Saturday, November 30, 2019 at 9:16:40 AM UTC-5, Richard Damon wrote: > >> > >> There are FPGAs which provide a 'gated clock' but they do the gating at > >> the row or region driver level, as that is where you get better power > >> savings (driving the clock tree is a significant use of power, while > >> gating at the flip-flop level saves virtually nothing, if it doesn't > >> cost you due to the extra logic, if it needs a LUT to gate, you have lost) > >> > >> These gated clock drivers tend to have de-glitching logic on them that > >> makes them safe to use (gate signal low keeps the output clock from > >> going high but doesn't force a high output low). This says that you can > >> save power if you know a whole section won't be changing for awhile, but > >> unlikely helps on a small state machine that occasionally doesn't > >> change, as the power in the change prediction logic may cost more than > >> the savings. Also, since these clock drivers are a limited critical > >> resource, you likely don't have enough to use it fine grain. > > > > Who makes these FPGAs? Are these in the typical clock generators most FPGAs have only a handful of? That's still better than no clock gating. > > > > Microsemi, now part of Microchip. The gating is part of the regional > clock driving tree, so is somewhat limited, but not as limited as the > master clock generators (which also have gating). Which products. I was just looking at their site the other day and I didn't see anything remotely new. Maybe I missed this? Or is this not new? -- Rick C. ++ Get 1,000 miles of free Supercharging ++ Tesla referral code - https://ts.la/richard11209Article: 161573
On Friday, November 29, 2019 at 10:56:36 PM UTC-5, Weng Tianxiang wrote: > 1. It became patent US 10482208 since 11/19/2019. >=20 OK, you paid your filing fee and convinced a bureaucrat so why are you goin= g on about it in comp.arch.fpga? > 2. If you can pinpoint any unsubstantiated claim from the official US pa= tent, what you make may invalidate the patent.=20 >=20 Why would I care to let you know about that? > 3. I welcome your action and have no objection against it, because I beli= eve the state machine's new coding method certainly will be accepted into H= DL SOMEDAY, because it generates no burden for coding state machines and fi= nally perfects the work made by a lot of papers one of which has 224 cites,= =20 > http://www.scarpaz.com/2100-papers/Low%20Power/00503933.pdf,=20 > and every code designer will benefit on the new coding method. >=20 As I pointed out to you before, because you've chosen to patent, it essenti= ally cannot be accepted into an HDL standard, regardless of the merit. >=20 > KJ, please be BRAVE to pinpoint WHICH PAGE, WHICH LINES =E5=93=A6=E4=BA= =BAWHICH FIGURES have any type of LOGIC and SIGNIFICANT errors. >=20 HAHAHAHA, that would be a paid position, not one that should be done for fr= ee. Good try. Just like the one you did earlier in this thread where you = encouraged others to be unethical to their own employers in regards to offe= ring a bounty for infringing your patent. Asking others to be unethical is= itself unethical, but I don't think you see it that way. > If you do this I will response to your points immediately and let Rick an= d HT-Lab determine if your claim is pointless or not, otherwise I will igno= re all your later posts on this subject.=20 You don't respond to any points...you reply, but no response. That's why w= e have these pointless back and forths, I point out your flaws or challenge= you to backup your claim with real data and you never come through. >=20 > 9 (nine) years ago I asked you to help me to check the application text f= or grammar errors and I thank you for your help with paying.=20 >=20 Grammar errors, right...OooooKkkkk. I provided valid technical feedback be= cause nearly everything you claimed at that time was wrong and I demonstrat= ed it to you with actual designs and reports. Grammar errors...I did do so= me of that too, but wow. > Now it became a patent with all brand new figures and specifications you = have never seen it before publication, and all figures, specification, clai= ms for the patent were made by myself. I've only been commenting on what you've posted here in this forum. You ju= st can't seem to follow...again Kevin JenningsArticle: 161574
On Saturday, November 30, 2019 at 8:09:50 AM UTC-5, Weng Tianxiang wrote: > The paper has a paragraph "4. Experiment Results" which uses their experiments to show it saves power. > > Weng > And where are your experimental results that demonstrate something useful compared to current state of the art? That's all I've been asking...for years Kevin
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