søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee:> On Sunday, July 4, 2021 at 12:07:12 PM UTC-7, gnuarm.del...@gmail.com wrote: > > On Sunday, July 4, 2021 at 2:50:39 PM UTC-4, Ed Lee wrote: > > > On Sunday, July 4, 2021 at 11:40:11 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote: > > > > > On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: > > > > > > > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter. > > > > > > How many LUTs is that? 10, 1,000, 100,000? > > > > > An 8051 would need more than 7680. > > > > I don't think that is right, but if so, another CPU would be advised. The sort of stack processors that are often used on FPGAs are as small as 500 LUTs. But why use a processor if it's not required? The point is everything I've heard about this does not require a processor at all. > > > > > > I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. > > > > > > > > > > > > I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. > > > > > Perhaps some, but not all features. It would be tough to do 100KHz sampling loop and low long term power budget with FPGA. > > > > Again, you know nothing about it. A 100 MHz timer is a very low power entity. The power used by any counter is treated as one FF toggling at the clock rate since each FF toggles at half the rate of the next faster one, so clock rate * (1/2 + 1/4 + 1/8...) ~= 1 * clock rate no matter the length. Add a comparator and you get 2 FF equivalent at 100 MHz. Not much current there. Counters are best implemented as down counters using the carry chain for the terminal count down from a variable starting value instead of a comparator so back to 1 FF if that will work in this app (it means you make the decision about cycle length when you load the counter, rather than as it approaches the end of the count). > > > Perhaps you should read the datasheet also. The ICE40 max out at 48MHz, it won't run at 100MHz. And i never said it need 100MHz counter. I only mention 100KHz sampling loop. At 48MHz, we are talking about mA supply current, not uA. > > Sorry, you are reading the wrong data. You might be looking at the configuration clock or something. The internal logic runs at hundreds of MHz. Go back and read some more. > The ICE40 internal RC peak at 48MHz. Stm32 internal RC peak at 180MHz. If we are comparing single chip solution, we should be comparing internal RC.it has a pll that can do several 100MHz
Fast simple microcontroller
Started by ●July 2, 2021
Reply by ●July 4, 20212021-07-04
Reply by ●July 4, 20212021-07-04
On Sunday, July 4, 2021 at 12:10:20 PM UTC-7, Ed Lee wrote:> On Sunday, July 4, 2021 at 12:07:12 PM UTC-7, gnuarm.del...@gmail.com wrote: > > On Sunday, July 4, 2021 at 2:50:39 PM UTC-4, Ed Lee wrote: > > > On Sunday, July 4, 2021 at 11:40:11 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote: > > > > > On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: > > > > > > > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter. > > > > > > How many LUTs is that? 10, 1,000, 100,000? > > > > > An 8051 would need more than 7680. > > > > I don't think that is right, but if so, another CPU would be advised. The sort of stack processors that are often used on FPGAs are as small as 500 LUTs. But why use a processor if it's not required? The point is everything I've heard about this does not require a processor at all. > > > > > > I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. > > > > > > > > > > > > I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. > > > > > Perhaps some, but not all features. It would be tough to do 100KHz sampling loop and low long term power budget with FPGA. > > > > Again, you know nothing about it. A 100 MHz timer is a very low power entity. The power used by any counter is treated as one FF toggling at the clock rate since each FF toggles at half the rate of the next faster one, so clock rate * (1/2 + 1/4 + 1/8...) ~= 1 * clock rate no matter the length. Add a comparator and you get 2 FF equivalent at 100 MHz. Not much current there. Counters are best implemented as down counters using the carry chain for the terminal count down from a variable starting value instead of a comparator so back to 1 FF if that will work in this app (it means you make the decision about cycle length when you load the counter, rather than as it approaches the end of the count). > > > Perhaps you should read the datasheet also. The ICE40 max out at 48MHz, it won't run at 100MHz. And i never said it need 100MHz counter. I only mention 100KHz sampling loop. At 48MHz, we are talking about mA supply current, not uA. > > Sorry, you are reading the wrong data. You might be looking at the configuration clock or something. The internal logic runs at hundreds of MHz. Go back and read some more. > The ICE40 internal RC peak at 48MHz. Stm32 internal RC peak at 180MHz. If we are comparing single chip solution, we should be comparing internal RC.Page 7: https://www.latticesemi.com/view_document?document_id=50666 Low Frequency Oscillator – 10 kHz High Frequency Oscillator – 48 MHz
Reply by ●July 4, 20212021-07-04
On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote:> søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee: > > On Sunday, July 4, 2021 at 12:07:12 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > On Sunday, July 4, 2021 at 2:50:39 PM UTC-4, Ed Lee wrote: > > > > On Sunday, July 4, 2021 at 11:40:11 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote: > > > > > > On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: > > > > > > > > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter. > > > > > > > How many LUTs is that? 10, 1,000, 100,000? > > > > > > An 8051 would need more than 7680. > > > > > I don't think that is right, but if so, another CPU would be advised. The sort of stack processors that are often used on FPGAs are as small as 500 LUTs. But why use a processor if it's not required? The point is everything I've heard about this does not require a processor at all. > > > > > > > I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. > > > > > > > > > > > > > > I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. > > > > > > Perhaps some, but not all features. It would be tough to do 100KHz sampling loop and low long term power budget with FPGA. > > > > > Again, you know nothing about it. A 100 MHz timer is a very low power entity. The power used by any counter is treated as one FF toggling at the clock rate since each FF toggles at half the rate of the next faster one, so clock rate * (1/2 + 1/4 + 1/8...) ~= 1 * clock rate no matter the length. Add a comparator and you get 2 FF equivalent at 100 MHz. Not much current there. Counters are best implemented as down counters using the carry chain for the terminal count down from a variable starting value instead of a comparator so back to 1 FF if that will work in this app (it means you make the decision about cycle length when you load the counter, rather than as it approaches the end of the count). > > > > Perhaps you should read the datasheet also. The ICE40 max out at 48MHz, it won't run at 100MHz. And i never said it need 100MHz counter. I only mention 100KHz sampling loop. At 48MHz, we are talking about mA supply current, not uA. > > > Sorry, you are reading the wrong data. You might be looking at the configuration clock or something. The internal logic runs at hundreds of MHz. Go back and read some more. > > The ICE40 internal RC peak at 48MHz. Stm32 internal RC peak at 180MHz. If we are comparing single chip solution, we should be comparing internal RC. > it has a pll that can do several 100MHzOK, it can go to 180MHz. The question is whether this is set by the bit stream or run-time configuration. Namely, can it switch between 32KHz and 180MHz at run time.
Reply by ●July 4, 20212021-07-04
On Sunday, July 4, 2021 at 3:29:35 PM UTC-4, Ed Lee wrote:> On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote: > > søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee: > > > On Sunday, July 4, 2021 at 12:07:12 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > > On Sunday, July 4, 2021 at 2:50:39 PM UTC-4, Ed Lee wrote: > > > > > On Sunday, July 4, 2021 at 11:40:11 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote: > > > > > > > On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: > > > > > > > > > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter. > > > > > > > > How many LUTs is that? 10, 1,000, 100,000? > > > > > > > An 8051 would need more than 7680. > > > > > > I don't think that is right, but if so, another CPU would be advised. The sort of stack processors that are often used on FPGAs are as small as 500 LUTs. But why use a processor if it's not required? The point is everything I've heard about this does not require a processor at all. > > > > > > > > I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. > > > > > > > > > > > > > > > > I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. > > > > > > > Perhaps some, but not all features. It would be tough to do 100KHz sampling loop and low long term power budget with FPGA. > > > > > > Again, you know nothing about it. A 100 MHz timer is a very low power entity. The power used by any counter is treated as one FF toggling at the clock rate since each FF toggles at half the rate of the next faster one, so clock rate * (1/2 + 1/4 + 1/8...) ~= 1 * clock rate no matter the length. Add a comparator and you get 2 FF equivalent at 100 MHz. Not much current there. Counters are best implemented as down counters using the carry chain for the terminal count down from a variable starting value instead of a comparator so back to 1 FF if that will work in this app (it means you make the decision about cycle length when you load the counter, rather than as it approaches the end of the count). > > > > > Perhaps you should read the datasheet also. The ICE40 max out at 48MHz, it won't run at 100MHz. And i never said it need 100MHz counter. I only mention 100KHz sampling loop. At 48MHz, we are talking about mA supply current, not uA. > > > > Sorry, you are reading the wrong data. You might be looking at the configuration clock or something. The internal logic runs at hundreds of MHz. Go back and read some more. > > > The ICE40 internal RC peak at 48MHz. Stm32 internal RC peak at 180MHz. If we are comparing single chip solution, we should be comparing internal RC. > > it has a pll that can do several 100MHz > OK, it can go to 180MHz. The question is whether this is set by the bit stream or run-time configuration. Namely, can it switch between 32KHz and 180MHz at run time.I don't know what you think you've found that says 180 MHz, but they typically don't give you a toggle rate for FFs as it is a meaningless number in any real design and only used for marketing purposes. Here is the spec on the PLL. Table 4.18. sysCLOCK PLL TimingParameterDescriptionsConditionsMinMaxUnitfINInput ClockFrequency (REFERENCECLK, EXTFEEDBACK)—10 133MHzfOUTOutput Clock Frequency (PLLOUT)—16 275MHz Unfortunately that's how it copies from the PDF. If you want to see it clearly find table 4.18. The max logic speed depends on the logic in your circuit. A decent job of design will let a counter run at the full 275 MHz of the PLL. Now, either learn something or go away. Stop being a Larkin. -- Rick C. -+-- Get 1,000 miles of free Supercharging -+-- Tesla referral code - https://ts.la/richard11209
Reply by ●July 4, 20212021-07-04
On Sunday, July 4, 2021 at 12:41:24 PM UTC-7, gnuarm.del...@gmail.com wrote:> On Sunday, July 4, 2021 at 3:29:35 PM UTC-4, Ed Lee wrote: > > On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote: > > > søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee: > > > > On Sunday, July 4, 2021 at 12:07:12 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > On Sunday, July 4, 2021 at 2:50:39 PM UTC-4, Ed Lee wrote: > > > > > > On Sunday, July 4, 2021 at 11:40:11 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote: > > > > > > > > On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: > > > > > > > > > > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter. > > > > > > > > > How many LUTs is that? 10, 1,000, 100,000? > > > > > > > > An 8051 would need more than 7680. > > > > > > > I don't think that is right, but if so, another CPU would be advised. The sort of stack processors that are often used on FPGAs are as small as 500 LUTs. But why use a processor if it's not required? The point is everything I've heard about this does not require a processor at all. > > > > > > > > > I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. > > > > > > > > > > > > > > > > > > I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. > > > > > > > > Perhaps some, but not all features. It would be tough to do 100KHz sampling loop and low long term power budget with FPGA. > > > > > > > Again, you know nothing about it. A 100 MHz timer is a very low power entity. The power used by any counter is treated as one FF toggling at the clock rate since each FF toggles at half the rate of the next faster one, so clock rate * (1/2 + 1/4 + 1/8...) ~= 1 * clock rate no matter the length. Add a comparator and you get 2 FF equivalent at 100 MHz. Not much current there. Counters are best implemented as down counters using the carry chain for the terminal count down from a variable starting value instead of a comparator so back to 1 FF if that will work in this app (it means you make the decision about cycle length when you load the counter, rather than as it approaches the end of the count). > > > > > > Perhaps you should read the datasheet also. The ICE40 max out at 48MHz, it won't run at 100MHz. And i never said it need 100MHz counter. I only mention 100KHz sampling loop. At 48MHz, we are talking about mA supply current, not uA. > > > > > Sorry, you are reading the wrong data. You might be looking at the configuration clock or something. The internal logic runs at hundreds of MHz. Go back and read some more. > > > > The ICE40 internal RC peak at 48MHz. Stm32 internal RC peak at 180MHz. If we are comparing single chip solution, we should be comparing internal RC. > > > it has a pll that can do several 100MHz > > OK, it can go to 180MHz. The question is whether this is set by the bit stream or run-time configuration. Namely, can it switch between 32KHz and 180MHz at run time. > I don't know what you think you've found that says 180 MHz, but they typically don't give you a toggle rate for FFs as it is a meaningless number in any real design and only used for marketing purposes. Here is the spec on the PLL. > > Table 4.18. sysCLOCK PLL TimingParameterDescriptionsConditionsMinMaxUnitfINInput ClockFrequency (REFERENCECLK, EXTFEEDBACK)—10 133MHzfOUTOutput Clock Frequency (PLLOUT)—16 275MHz > > Unfortunately that's how it copies from the PDF. If you want to see it clearly find table 4.18. > > The max logic speed depends on the logic in your circuit. A decent job of design will let a counter run at the full 275 MHz of the PLL.Page 34: Maximum global clock of 185MHz. Anyway, the critical issue is whether you can switch between low speed (32KHz) and high speed (185MHz) as in a micro. Micros have registers to write into, not FPGA.
Reply by ●July 4, 20212021-07-04
On Sunday, July 4, 2021 at 3:46:16 PM UTC-4, Ed Lee wrote:> On Sunday, July 4, 2021 at 12:41:24 PM UTC-7, gnuarm.del...@gmail.com wrote: > > On Sunday, July 4, 2021 at 3:29:35 PM UTC-4, Ed Lee wrote: > > > On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote: > > > > søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee: > > > > > On Sunday, July 4, 2021 at 12:07:12 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > On Sunday, July 4, 2021 at 2:50:39 PM UTC-4, Ed Lee wrote: > > > > > > > On Sunday, July 4, 2021 at 11:40:11 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote: > > > > > > > > > On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > > > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: > > > > > > > > > > > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter. > > > > > > > > > > How many LUTs is that? 10, 1,000, 100,000? > > > > > > > > > An 8051 would need more than 7680. > > > > > > > > I don't think that is right, but if so, another CPU would be advised. The sort of stack processors that are often used on FPGAs are as small as 500 LUTs. But why use a processor if it's not required? The point is everything I've heard about this does not require a processor at all. > > > > > > > > > > I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. > > > > > > > > > > > > > > > > > > > > I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. > > > > > > > > > Perhaps some, but not all features. It would be tough to do 100KHz sampling loop and low long term power budget with FPGA. > > > > > > > > Again, you know nothing about it. A 100 MHz timer is a very low power entity. The power used by any counter is treated as one FF toggling at the clock rate since each FF toggles at half the rate of the next faster one, so clock rate * (1/2 + 1/4 + 1/8...) ~= 1 * clock rate no matter the length. Add a comparator and you get 2 FF equivalent at 100 MHz. Not much current there. Counters are best implemented as down counters using the carry chain for the terminal count down from a variable starting value instead of a comparator so back to 1 FF if that will work in this app (it means you make the decision about cycle length when you load the counter, rather than as it approaches the end of the count). > > > > > > > Perhaps you should read the datasheet also. The ICE40 max out at 48MHz, it won't run at 100MHz. And i never said it need 100MHz counter. I only mention 100KHz sampling loop. At 48MHz, we are talking about mA supply current, not uA. > > > > > > Sorry, you are reading the wrong data. You might be looking at the configuration clock or something. The internal logic runs at hundreds of MHz. Go back and read some more. > > > > > The ICE40 internal RC peak at 48MHz. Stm32 internal RC peak at 180MHz. If we are comparing single chip solution, we should be comparing internal RC. > > > > it has a pll that can do several 100MHz > > > OK, it can go to 180MHz. The question is whether this is set by the bit stream or run-time configuration. Namely, can it switch between 32KHz and 180MHz at run time. > > I don't know what you think you've found that says 180 MHz, but they typically don't give you a toggle rate for FFs as it is a meaningless number in any real design and only used for marketing purposes. Here is the spec on the PLL. > > > > Table 4.18. sysCLOCK PLL TimingParameterDescriptionsConditionsMinMaxUnitfINInput ClockFrequency (REFERENCECLK, EXTFEEDBACK)—10 133MHzfOUTOutput Clock Frequency (PLLOUT)—16 275MHz > > > > Unfortunately that's how it copies from the PDF. If you want to see it clearly find table 4.18. > > > > The max logic speed depends on the logic in your circuit. A decent job of design will let a counter run at the full 275 MHz of the PLL. > Page 34: Maximum global clock of 185MHz. Anyway, the critical issue is whether you can switch between low speed (32KHz) and high speed (185MHz) as in a micro. Micros have registers to write into, not FPGA.Table 4.17. iCE40 Ultra External Switching Characteristics Did you see the word "external" there? That's the max rate on the I/O pin, not the internal clocking. Try reading the data sheets and learn how it works. Why do you want to switch the clock speed? Just run the parts that need 32 kHz from 32 kHz and run the fast parts from the fast clock. What's the point of running the fast parts from a slow clock? You are stuck in the hugely awkward mindset of MCUs which do things in a certain way because they don't have choices. Do you want to generate a 100 kHz waveform from a 32 kHz clock? I thought you wanted to run a slow timer so it would be low power and shut off the clock to the rest of the chip so it would not draw power. Do I have this wrong somehow? This is always your problem. You can't let go of your mindset or even explain it enough to communicate. -- Rick C. -+-+ Get 1,000 miles of free Supercharging -+-+ Tesla referral code - https://ts.la/richard11209
Reply by ●July 4, 20212021-07-04
On Sunday, July 4, 2021 at 1:05:11 PM UTC-7, gnuarm.del...@gmail.com wrote:> On Sunday, July 4, 2021 at 3:46:16 PM UTC-4, Ed Lee wrote: > > On Sunday, July 4, 2021 at 12:41:24 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > On Sunday, July 4, 2021 at 3:29:35 PM UTC-4, Ed Lee wrote: > > > > On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote: > > > > > søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee: > > > > > > On Sunday, July 4, 2021 at 12:07:12 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > On Sunday, July 4, 2021 at 2:50:39 PM UTC-4, Ed Lee wrote: > > > > > > > > On Sunday, July 4, 2021 at 11:40:11 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > > On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote: > > > > > > > > > > On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > > > > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: > > > > > > > > > > > > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter. > > > > > > > > > > > How many LUTs is that? 10, 1,000, 100,000? > > > > > > > > > > An 8051 would need more than 7680. > > > > > > > > > I don't think that is right, but if so, another CPU would be advised. The sort of stack processors that are often used on FPGAs are as small as 500 LUTs. But why use a processor if it's not required? The point is everything I've heard about this does not require a processor at all. > > > > > > > > > > > I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. > > > > > > > > > > > > > > > > > > > > > > I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. > > > > > > > > > > Perhaps some, but not all features. It would be tough to do 100KHz sampling loop and low long term power budget with FPGA. > > > > > > > > > Again, you know nothing about it. A 100 MHz timer is a very low power entity. The power used by any counter is treated as one FF toggling at the clock rate since each FF toggles at half the rate of the next faster one, so clock rate * (1/2 + 1/4 + 1/8...) ~= 1 * clock rate no matter the length. Add a comparator and you get 2 FF equivalent at 100 MHz. Not much current there. Counters are best implemented as down counters using the carry chain for the terminal count down from a variable starting value instead of a comparator so back to 1 FF if that will work in this app (it means you make the decision about cycle length when you load the counter, rather than as it approaches the end of the count). > > > > > > > > Perhaps you should read the datasheet also. The ICE40 max out at 48MHz, it won't run at 100MHz. And i never said it need 100MHz counter. I only mention 100KHz sampling loop. At 48MHz, we are talking about mA supply current, not uA. > > > > > > > Sorry, you are reading the wrong data. You might be looking at the configuration clock or something. The internal logic runs at hundreds of MHz. Go back and read some more. > > > > > > The ICE40 internal RC peak at 48MHz. Stm32 internal RC peak at 180MHz. If we are comparing single chip solution, we should be comparing internal RC. > > > > > it has a pll that can do several 100MHz > > > > OK, it can go to 180MHz. The question is whether this is set by the bit stream or run-time configuration. Namely, can it switch between 32KHz and 180MHz at run time. > > > I don't know what you think you've found that says 180 MHz, but they typically don't give you a toggle rate for FFs as it is a meaningless number in any real design and only used for marketing purposes. Here is the spec on the PLL. > > > > > > Table 4.18. sysCLOCK PLL TimingParameterDescriptionsConditionsMinMaxUnitfINInput ClockFrequency (REFERENCECLK, EXTFEEDBACK)—10 133MHzfOUTOutput Clock Frequency (PLLOUT)—16 275MHz > > > > > > Unfortunately that's how it copies from the PDF. If you want to see it clearly find table 4.18. > > > > > > The max logic speed depends on the logic in your circuit. A decent job of design will let a counter run at the full 275 MHz of the PLL. > > Page 34: Maximum global clock of 185MHz. Anyway, the critical issue is whether you can switch between low speed (32KHz) and high speed (185MHz) as in a micro. Micros have registers to write into, not FPGA. > Table 4.17. iCE40 Ultra External Switching Characteristics > > Did you see the word "external" there? That's the max rate on the I/O pin, not the internal clocking. > > Try reading the data sheets and learn how it works. > > Why do you want to switch the clock speed? Just run the parts that need 32 kHz from 32 kHz and run the fast parts from the fast clock. What's the point of running the fast parts from a slow clock? You are stuck in the hugely awkward mindset of MCUs which do things in a certain way because they don't have choices. > > Do you want to generate a 100 kHz waveform from a 32 kHz clock? I thought you wanted to run a slow timer so it would be low power and shut off the clock to the rest of the chip so it would not draw power. Do I have this wrong somehow? > > This is always your problem. You can't let go of your mindset or even explain it enough to communicate.Your problem is just always making assumptions in your favour. It's very common to run micros at maximum speed to process the loop, then sleep (basically dropping to lowest speed) and wait for timer/interrupt. The purposed app is 24V to 200V DC/DC, if i read previous posts correctly. The micro or fpga does not need to run constantly, especially if there is storage device (battery or cap) involved. All i am saying is that micro will have better power management than fpga.
Reply by ●July 4, 20212021-07-04
On 03/07/2021 13.58, piglet wrote:> On 02/07/2021 16:45, Klaus Vestergaard Kragelund wrote: >> On 02/07/2021 07.33, Anthony William Sloman wrote: >>> I've been thinking about Timo's inverter, and it looks as if a >>> micro-controller that offered a 100MHz clock rate would be fast >>> enough to do a decent job of switching the Siliconix Si3440DV >>> DMOSFet that I fancy. >>> >> I have been a little absent from SED the last couple of months, got a >> consulting gig in parallel with my day job >> >> Can you post a link to the Timo inverter? >> >> Cheers >> >> Klaus > Look back a few weeks in SED for thread "Low noise high bias voltage > ..." - basically a call for ideas on a low noise high voltage low power > inverter. > > Bill Sloman is now exploring using very fast mcus to generate square > wave drive for the current fed center tap push-pull converter he is > fascinated with. >Thanks, I searched back and found it :-) Very nice discussion, and also this thread which is technical instead of all that OT. In fact I am working on something vaguely similar. Also a micro driving a converter. Right now it is hard-driven, but have been thinking about using it in resonant mode Resonant mode is a little difficult in that the loop gain is nonlinear. Most resonant controllers use a charge transfer principle, to avoid this non-liniarity. That is not simple to implement in a micro
Reply by ●July 4, 20212021-07-04
On Sunday, July 4, 2021 at 3:51:42 PM UTC-7, Klaus Kragelund wrote:> On 03/07/2021 13.58, piglet wrote: > > On 02/07/2021 16:45, Klaus Vestergaard Kragelund wrote: > >> On 02/07/2021 07.33, Anthony William Sloman wrote: > >>> I've been thinking about Timo's inverter, and it looks as if a > >>> micro-controller that offered a 100MHz clock rate would be fast > >>> enough to do a decent job of switching the Siliconix Si3440DV > >>> DMOSFet that I fancy. > >>> > >> I have been a little absent from SED the last couple of months, got a > >> consulting gig in parallel with my day job > >> > >> Can you post a link to the Timo inverter? > >> > >> Cheers > >> > >> Klaus > > Look back a few weeks in SED for thread "Low noise high bias voltage > > ..." - basically a call for ideas on a low noise high voltage low power > > inverter. > > > > Bill Sloman is now exploring using very fast mcus to generate square > > wave drive for the current fed center tap push-pull converter he is > > fascinated with. > > > Thanks, I searched back and found it :-) > > Very nice discussion, and also this thread which is technical instead of > all that OT. > > In fact I am working on something vaguely similar. Also a micro driving > a converter. Right now it is hard-driven, but have been thinking about > using it in resonant mode > > Resonant mode is a little difficult in that the loop gain is nonlinear. > Most resonant controllers use a charge traearnsfer principle, to avoid this > non-liniarity. That is not simple to implement in a microiesI am also planning on same with inductor or transformer, driving with high frequency counter. Non-linear loop gain is not a problem, as long as the output is above the target, excess energy will be dumped into the super-caps or batteries. Power transfer efficiency is more important.
Reply by ●July 5, 20212021-07-05
On Sunday, July 4, 2021 at 4:22:35 PM UTC-4, Ed Lee wrote:> On Sunday, July 4, 2021 at 1:05:11 PM UTC-7, gnuarm.del...@gmail.com wrote: > > On Sunday, July 4, 2021 at 3:46:16 PM UTC-4, Ed Lee wrote: > > > On Sunday, July 4, 2021 at 12:41:24 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > > On Sunday, July 4, 2021 at 3:29:35 PM UTC-4, Ed Lee wrote: > > > > > On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote: > > > > > > søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee: > > > > > > > On Sunday, July 4, 2021 at 12:07:12 PM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > On Sunday, July 4, 2021 at 2:50:39 PM UTC-4, Ed Lee wrote: > > > > > > > > > On Sunday, July 4, 2021 at 11:40:11 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > > > On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote: > > > > > > > > > > > On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: > > > > > > > > > > > > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: > > > > > > > > > > > > > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter. > > > > > > > > > > > > How many LUTs is that? 10, 1,000, 100,000? > > > > > > > > > > > An 8051 would need more than 7680. > > > > > > > > > > I don't think that is right, but if so, another CPU would be advised. The sort of stack processors that are often used on FPGAs are as small as 500 LUTs. But why use a processor if it's not required? The point is everything I've heard about this does not require a processor at all. > > > > > > > > > > > > I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. > > > > > > > > > > > > > > > > > > > > > > > > I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. > > > > > > > > > > > Perhaps some, but not all features. It would be tough to do 100KHz sampling loop and low long term power budget with FPGA. > > > > > > > > > > Again, you know nothing about it. A 100 MHz timer is a very low power entity. The power used by any counter is treated as one FF toggling at the clock rate since each FF toggles at half the rate of the next faster one, so clock rate * (1/2 + 1/4 + 1/8...) ~= 1 * clock rate no matter the length. Add a comparator and you get 2 FF equivalent at 100 MHz. Not much current there. Counters are best implemented as down counters using the carry chain for the terminal count down from a variable starting value instead of a comparator so back to 1 FF if that will work in this app (it means you make the decision about cycle length when you load the counter, rather than as it approaches the end of the count). > > > > > > > > > Perhaps you should read the datasheet also. The ICE40 max out at 48MHz, it won't run at 100MHz. And i never said it need 100MHz counter. I only mention 100KHz sampling loop. At 48MHz, we are talking about mA supply current, not uA. > > > > > > > > Sorry, you are reading the wrong data. You might be looking at the configuration clock or something. The internal logic runs at hundreds of MHz. Go back and read some more. > > > > > > > The ICE40 internal RC peak at 48MHz. Stm32 internal RC peak at 180MHz. If we are comparing single chip solution, we should be comparing internal RC. > > > > > > it has a pll that can do several 100MHz > > > > > OK, it can go to 180MHz. The question is whether this is set by the bit stream or run-time configuration. Namely, can it switch between 32KHz and 180MHz at run time. > > > > I don't know what you think you've found that says 180 MHz, but they typically don't give you a toggle rate for FFs as it is a meaningless number in any real design and only used for marketing purposes. Here is the spec on the PLL. > > > > > > > > Table 4.18. sysCLOCK PLL TimingParameterDescriptionsConditionsMinMaxUnitfINInput ClockFrequency (REFERENCECLK, EXTFEEDBACK)—10 133MHzfOUTOutput Clock Frequency (PLLOUT)—16 275MHz > > > > > > > > Unfortunately that's how it copies from the PDF. If you want to see it clearly find table 4.18. > > > > > > > > The max logic speed depends on the logic in your circuit. A decent job of design will let a counter run at the full 275 MHz of the PLL. > > > Page 34: Maximum global clock of 185MHz. Anyway, the critical issue is whether you can switch between low speed (32KHz) and high speed (185MHz) as in a micro. Micros have registers to write into, not FPGA. > > Table 4.17. iCE40 Ultra External Switching Characteristics > > > > Did you see the word "external" there? That's the max rate on the I/O pin, not the internal clocking. > > > > Try reading the data sheets and learn how it works. > > > > Why do you want to switch the clock speed? Just run the parts that need 32 kHz from 32 kHz and run the fast parts from the fast clock. What's the point of running the fast parts from a slow clock? You are stuck in the hugely awkward mindset of MCUs which do things in a certain way because they don't have choices. > > > > Do you want to generate a 100 kHz waveform from a 32 kHz clock? I thought you wanted to run a slow timer so it would be low power and shut off the clock to the rest of the chip so it would not draw power. Do I have this wrong somehow? > > > > This is always your problem. You can't let go of your mindset or even explain it enough to communicate. > Your problem is just always making assumptions in your favour. It's very common to run micros at maximum speed to process the loop, then sleep (basically dropping to lowest speed) and wait for timer/interrupt.Which is exactly what an FPGA would do. You still have zero understanding of the problem and the solution.> The purposed app is 24V to 200V DC/DC, if i read previous posts correctly. The micro or fpga does not need to run constantly, especially if there is storage device (battery or cap) involved. All i am saying is that micro will have better power management than fpga.Whatever. You don't know a damn thing about FPGAs, but you are hell bent on proving your assertion regardless of the facts. Since you know your conclusion you don't need to actually do anything to learn about FPGAs. Enough said. Enjoy your ignorance. -- Rick C. -++- Get 1,000 miles of free Supercharging -++- Tesla referral code - https://ts.la/richard11209
