"summing" lookup tables

There is no point to viewing FFs the way you describe. You are correct tha t FFs allow designers to focus on the logic. That is the entire point of s ynchronous design. But calling a FF an ASM is without value. It is a FF. Calling it an ASM is a bit like saying an internal combustion engine is "s olar powered" because the oil it burns came from plants and animals that gr ew because of the sun. Without value.

I know how FFs work. Mostly they are transmission gates and inverting devi ces. I design boards and mostly ignore the fine details of how chips are m ade since learning that is much more info than is practically useful.

I did see a very convoluted gate diagram of a 74xx112 JK FF. I thought abo ut tracing out the signal flow, but decided I needed to spend time on usefu l things.

--

  Rick C. 

  --- Get 1,000 miles of free Supercharging 
  --- Tesla referral code - https://ts.la/richard11209

I'm not asking you to explain logic gates. I'm asking you what you mean. That's ok, it's not really a useful topic.

--

  Rick C. 

  --+ Get 1,000 miles of free Supercharging 
  --+ Tesla referral code - https://ts.la/richard11209

[...] [...] [...]

Fair enough. We all select the levels of abstraction we're comfortable with.

Jeroen Belleman

Precisely. I don't see why Ricky C can't understand that.

Yes indeed - and then they will decide they understand why synchronous state machines are much easier to design and implement :)

That's why I was surprised to see the GreenPAK stuff make a big deal of ASM.

I repeatedly see the practical consequences of people not understanding those fundamental points.

Clearly you lack fundamental insight. FFs are the classic pedagogical example of ASMs :)

No, you clearly /don't/ know how FFs work. If you think you do, start by considering how you make TTL or ECL FFs, where there are no transmission gates.

If you persist, then have a look at the circuit diagram for a 7474, where you can see all the transistors and resistors.

That is clear, and shows a lack of curiosity on your part.

I don't blame you. The operation is subtle; start by considering why the "bridging terms" are necessary.

I explained my error, man! a 3 LUT has 2^3 bits of storage and a 4 LUT has 2^4 bits of storage. Putting the output of one into an input of the other gets you an annoying-to-use 2^3 + 2^4 arbitrary outputs from 6 inputs (annoying because the input to output function is not one-to-one across the domain of the 6 input variables) but that's not 64.

Running the output of two LUTs into an OR gate would be equivalent I believe, you get 2^(N1) + 2^(N2) possible unique states, not 2^(N1 + N2). the states where both tables are outputting 1 into the OR gate are not unique. But then you have an extra "free" variable on the input side

If you need big LUTs then these little GreenPAKs are the wrong part, fortunately I don't really need it.

It's a mixed-signal chip, there are analog comparators on board you can use to fire state transitions.

I think they mean "asynchronous" in the sense it's asynchronous in the way you would write an "asynchronous" state-machine on a computer or uP, it's clocked to the system clock and all your user-transition inputs are expected to be much slower than that. You don't have to feed it a clock signal explicitly, but nothing really happens "simultaneously"

There are only a couple analog comparators on board it's prolly not hard to make a user-transparent priority queue gate for their (digital) outputs that ensures two or more never fire on exactly the same system clock, seems like a thing you'd have to do when mixing signals in a arbitrarily configurable way like that.

I wondered about that, but...

Looking at one of the datasheets (in acroread, since they don't render properly in okular nor evince!) it looks like they really are clockless...

18.5 Asynchronous State Machines vs. Synchronous State Machines It is important to note that this macrocell is designed for asynchronous operation, which means the following:

1. No clock source is needed, it reacts only to input signals.
2. The input signals do not have to be synchronized to each other, the macrocell will react to the earliest valid signal for state transition.
3. This macrocell does not have traditional set-up and hold time specifications which are related to incoming clock, as this macrocell has no clock source.
4. The macrocell only consumes power while in state transition.

(and the minimum width can be 5ns)

And a bit further on there are statements that make me think "oh yes, really? More explanation please" (N.B. Tst_comp is 5ns)

18.8.2 State Transition Competing Input Timing There will be situations where two input signals can be valid inputs that will drive two different state transitions from a given state. In that sense, the two signals are ?competing? (signals a and b in Figure 94), and the signal that arrives sooner should drive the state transition that will ?win?, or drive the state transition. If one signal arrives Tst_comp before the other one, it is guaranteed to win, and the state transition that it codes for will be taken, as shown in Figure 95. If the two signals arrive within Tst_comp of each other, it will be indeterminate which state transition will win, but one of the transitions will take place as long as the winning signal satisfies the pulse width criteria described in the paragraph above, as shown in Figure 96.

her

of

wish to

of

if

o 6

think

e 4

rs

n e

ut

ave to program each LUT separately and then connect them?

I understand your error, it is your language that is hard to follow. When you say "table into table" you mean feed the output of one LUT into another . Got it.

Yes, we've already covered the lack of full coverage with the cascade of tw o LUTs of all possible functions of N bits 2^(2^N). The way you describe y ou would get 2^(2^N1)*2^(2^N2) which would be 2^((2^N1)+(2^N2)) which is th e equivalent of a ~4.5 bit LUT.

our 16 bit tables. Each table will correspond to one 4LUT and all will use the same 4 inputs. The outputs of these tables can be combined 2 into 1 w ith a pair of 3LUTs as 2 to 1 muxes using one more input bit as the select, then a final 2 to 1 mux with the remaining input bit as the select.

download their software and see what the parts will do. I'm not expecting much.

Large LUTs are seldom needed, but when they are it can be less than accepta ble to implement a full 6LUT using 4LUTs, using lots of real estate and slo w. For many functions the simple cascade will work quite well.

--

  Rick C. 

  -+- Get 1,000 miles of free Supercharging 
  -+- Tesla referral code - https://ts.la/richard11209